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. ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
