Please post to the list too when replying...
On Wed, 2005-03-09 at 17:29, Mican Bican wrote:
> Thank you for your answer. The reason of so long transactions is that
> I first Insert a row than get the last ID (primary key) and select it
> for update from the database and wait for user to commit it..
> I need the key becouse I will insert rows with references to this new
> row (like adresses to user etc.) ..so the user cann add some adresses
> to a user and when he press ok I commit the statement...
>
I can't see why you couldn't insert the user in a first transaction and
the addresses in further transactions... if the user gets deleted in the
meantime by somebody else, then inserting the address will fail and you
will tell the user about the error. And if you don't want other people
to see the new user before it is committed with all it's addresses, then
collect first the user data + all the address data, and then open a
transaction and insert the user and the addresses when the user presses
OK. The point is that there should not be any GUI activity between the
start and end of a transaction.
If you really need a lock (I doubt it) between updates, implement it
using some application logic, don't use the DB row locking for long
living locks. I think there is some locking helper in the contrib
modules of postgres, or if not, read up on resource locking on google.
Cheers,
Csaba.