Tom Lane wrote:
>See
>http://www.postgresql.org/docs/7.4/static/explicit-locking.html
>
>
I saw.
Now - as a beginner in the transaction-locking stuff - I'm wondering
about the last paragraph.
"So long as no deadlock situation is detected, a transaction seeking
either a table-level or row-level lock will wait indefinitely for
conflicting locks to be released. This means it is a bad idea for
applications to hold transactions open for long periods of time (e.g.,
while waiting for user input)."
I'm working on an MsAccess application that uses PG as backend. Up until
recently I didn't bother for cuncurrency issues but I like to improve
things now that PG manages the data.
For this application I read records into forms and subforms.
If - by accident - 2 users open one record, say customer #123, and I
start a transaction on opening the form and SELECT ... FOR UPDATE to
read data, then the second user's application stalls until the first
COMMITs.
With SELECT without FOR UPDATE the UPDATEs of the first committing
transaction get overwritten.
I can't predict how long a user lets open a form. I just need to protect
the displayd data against updates in the meantime.
This must be a common problem regardless what client software is used.
Are there some guidelines on locks for forms ?
Regards
Andreas
