At 06:36 PM 10/2/2001, Hiroshi Inoue wrote:
>The cause is that the stored function uses a common
>snapshot throughout the function execution. As I've
>complained many times, the current implementaion is
>far from intuition and this case seems to show that
>it isn't proper at all either.
Bravo! That indeed seems to have been the problem. To solve it, I simply
moved the LOCK TABLE out of the PLpgSQL function and into the JDBC code.
While this isn't *ideal* as it leaves the table locked across two JDBC
calls (the function and the following commit), it achieves the desired
result (synchronous access to the idfactory table across all clients), and
as I said, the function won't be called very often. It's far more important
that it work as expected rather than it work in sub-millisecond time.
To illustrate then what seems to have been occurring:
Time Thread A Thread B
1 snapshot
2 lock
3 read 1, 1
4 write 11, 2
5 snapshot
6 return 1
7 commit
8 lock
9 read 1, 1
10 write 11, 2
11 FAIL
As long as thread B takes its snapshot any time before the commit at (7),
its write at (10) will not affect any rows because ...
>The *update* statement
>find the row matching the where clause using the common
>snapshot but will find the row was already updated and
>the updated row doesn't satisfy the condition any longer.
Ouch. So querying for select, update, delete, whatever goes against the
snapshot to *locate* rows, but then applies the where clause to the *new
values* not seen in the snapshot? If that's the case, that's extremely
confusing.
Anyway, many thanks to everyone for keeping me from going totally insane.
Luckily the other stored procedures we need to write won't require such
strict access to table data. :)
Peace,
Dave
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
