2011/5/4 durumdara <durumdara(at)gmail(dot)com>:
> We will porting an application to PGSQL from some table based app (BDE
> 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
> 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
> 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
> 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...
(aside: borland delphi is increasingly obsolete in the scheme of
things, but zeos is one of the best postgres drivers ever written!)
In response to
pgsql-general by date
|Next:||From: Tom Lane||Date: 2011-05-04 20:42:41|
|Subject: Re: GROUP BY Wildcard Syntax Thought |
|Previous:||From: Misa Simic||Date: 2011-05-04 19:39:02|
|Subject: Re: pervasiveness of surrogate (also called synthetic) keys|