Re: No exception with concurrent updates

Dave,

On Jul 14 2004, Dave Cramer wrote:

> Vladimir,
>
> This simply won't work, you will need to either synchronize transaction,
> or use some other locking mechanism. As I said, postgres supports
> concurrent transactions, they will both succeed simultaneously.
>
I thought that this is taken care of when you set TRANSACTION_SERIALIZABLE on
the Connection object.

> Your options are select the row for update, which will lock it from
> other transactions updating it.
>
> synchronize transaction so that only one gets in there at a time.
>
> use pessimistic locking which involves a timestamp and you have to check
> to make sure that the row has not changed before you update it, although
> without synchronization this won't work either.
>
> Dave
>
>
This programme was a part of the comparison between PostgreSQL and InterBase
(known now under name Firebird for open source developement) regarding their
concurrent updates handling, which as I know doesn't use 2 Phase Commit either.
The term for MVCC in IB is multi-generational database architecture. By the way
there exist the NO WAIT parameter in IB, which can be specified when starting a
transaction and does not require a transaction to wait until the end of
concurrent transaction. Using this mode the first version of my programme
(without threads) did not halt - I received the exception and the second
transaction's update did not commit.

Thanks for the prompt responses,

Vladimir

________________________________________________________________________

Vladimir Stankovic Tel: +44 20 7040 0273
Research Student Fax: +44 20 7040 8585
Centre for Software Reliability Email: V(dot)Stankovic(at)city(dot)ac(dot)uk
City University
Northampton Square, London EC1V 0HB
________________________________________________________________________

Yes, you are correct, it should be handled properly in this case, you
should look at the logs in the postgresl log, to see what is really
going on, it is possible they truly aren't concurrent.

Set logpid on, and log statement

Dave
On Wed, 2004-07-14 at 17:36, Vladimir Stankovic wrote:
> Dave,
>
> On Jul 14 2004, Dave Cramer wrote:
>
> > Vladimir,
> >
> > This simply won't work, you will need to either synchronize transaction,
> > or use some other locking mechanism. As I said, postgres supports
> > concurrent transactions, they will both succeed simultaneously.
> >
> I thought that this is taken care of when you set TRANSACTION_SERIALIZABLE on
> the Connection object.
>
> > Your options are select the row for update, which will lock it from
> > other transactions updating it.
> >
> > synchronize transaction so that only one gets in there at a time.
> >
> > use pessimistic locking which involves a timestamp and you have to check
> > to make sure that the row has not changed before you update it, although
> > without synchronization this won't work either.
> >
> > Dave
> >
> >
> This programme was a part of the comparison between PostgreSQL and InterBase
> (known now under name Firebird for open source developement) regarding their
> concurrent updates handling, which as I know doesn't use 2 Phase Commit either.
> The term for MVCC in IB is multi-generational database architecture. By the way
> there exist the NO WAIT parameter in IB, which can be specified when starting a
> transaction and does not require a transaction to wait until the end of
> concurrent transaction. Using this mode the first version of my programme
> (without threads) did not halt - I received the exception and the second
> transaction's update did not commit.
>
> Thanks for the prompt responses,
>
> Vladimir
>
> ________________________________________________________________________
>
> Vladimir Stankovic Tel: +44 20 7040 0273
> Research Student Fax: +44 20 7040 8585
> Centre for Software Reliability Email: V(dot)Stankovic(at)city(dot)ac(dot)uk
> City University
> Northampton Square, London EC1V 0HB
> ________________________________________________________________________
>
>
>
>
> !DSPAM:40f5a78e197681998034425!
>
>
--
Dave Cramer
519 939 0336
ICQ # 14675561