Skip site navigation (1) Skip section navigation (2)

Re: ZEOS or PGDAC - How to lock a resource?

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: durumdara <durumdara(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: ZEOS or PGDAC - How to lock a resource?
Date: 2011-05-04 20:31:14
Message-ID: BANLkTikfb6G79213dv6CDhUEYQhgfW_y4g@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-general
2011/5/4 durumdara <durumdara(at)gmail(dot)com>:
> Hi!
>
> We will porting an application to PGSQL from some table based app (BDE
> like).
>
> The older application used a special technic of the driver: if a record
> edited, some exclusive (over transaction), "forever living" lock put on it.
> On exit, cancel, or post this lock removed.
>
> We used this to lock the main resource from concurrent edits.
>
> For example:
> A product (a Car) have many properties and sublists (details), like color,
> transport date, elements (what we need to build into car: wheel, etc), bill
> informations, subtransport times, etc.
> Because ALL of them is the product, we must protect it with "Edit lock" on
> open.
> The subinformations are easily editable, and postable (there is autocommit).
>
> Now I search for some technics in PGSQL.
> As I read, the locks are transaction depended, because they are vanishes on
> rollback/commit.
>
> But we want to save the subelements on editing (one by one), not on saving
> the main.
> This meaning that we break the transaction with commit - ergo the lock
> vanish.
>
> For example:
> Car Edit:
> - Lock This car
> - Edit color
> - Open product elements tab
> - Add two new elements
> - Save them (ApplyUpdates, Commit)
> - Add a bill date
> - Save it (Apply, Commit)
> - Post car record (Apply, Commit)
> - Release resource
> - Close Form
>
> I read the help, but I saw only transaction-dependent locks.
>
> Zeos or PGDAC is not like IBX/IBO (Firebird), so they don't have Transaction
> Component, I can use only one transaction by connection.
>
> How can I do a lock mechanism that:
> - Session based
> - No limit on how many I used
> - Linked to a Row, or a Resource Name
> - I can test to is it exists or not
>
> Like Mutex in Windows, but in PGSQL...

advisory locks
http://www.postgresql.org/docs/current/interactive/functions-admin.html#FUNCTIONS-ADVISORY-LOCKS

(aside: borland delphi is increasingly obsolete in the scheme of
things, but zeos is one of the best postgres drivers ever written!)


merlin

In response to

Responses

pgsql-general by date

Next:From: Tom LaneDate: 2011-05-04 20:42:41
Subject: Re: GROUP BY Wildcard Syntax Thought
Previous:From: Misa SimicDate: 2011-05-04 19:39:02
Subject: Re: pervasiveness of surrogate (also called synthetic) keys

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group