On Jul 14 2004, Dave Cramer wrote:
> I'm not sure what you are doing in debug mode, but neither of these
> updates should be blocked, as you are not locking the rows.
>
I used debug only to see where the programme execution stops.
> In order to lock the row you would need to select for update in one or
> both of the transactions.
> As far as MVCC goes the last one that goes through wins, not the first,
> since each transaction sees a snapshot of the data at the time that the
> transaction starts. So if ol_quantity is 5 before both transactions then
> assuming you open them at the same time they will both see 5 there, then
> one will update to 10, and the second will update to 20.
This is exactly what happened when I introduced threads in the programme (see
the programme listing below). And since the execution of the threads is
non-deterministic I sometimes end-up with the ol_quantity having the value of
the first update. Did I fulfill the necessary condition to start the
transactions at the same time? But i still don't understand why the programme
didn't finish in the previous version.
>
> there is more information here
>
> http://www.postgresql.org/docs/7.4/interactive/transaction-iso.html
>
> Dave
Vladimir
________________________________________________________________________
Vladimir Stankovic Tel: +44 20 7040 0273
Research Student Fax: +44 20 7040 8585
Centre for Software Reliability Email: V.Stankovic@city.ac.uk
City University
Northampton Square, London EC1V 0HB
________________________________________________________________________