Jurgen Defurne wrote:
>
> Andrew Sullivan wrote:
>
> > On Thu, Jun 15, 2000 at 12:45:52AM +0200, Jan Wieck wrote:
> >
> > > Believe it or not, but holding pure DB locks over
> > > "interaction" in an interactive application isn't what you
> > > really want! The user might go for coffee, and such long time
> > > locks are not what the locking mechanism of databases is
> > > intended for - so it's not optimized for this kind of abuse!
> >
> > Allow me to echo the above sentiment. Our library automation system is
> > built on a PICK back end (UniVerse), and the implementation locks any
>
> Why is a transaction better than a lock ? I have worked with locks without
> transactions
> and locks with transactions, and transactions alone. When you have two
> transactions
> on the same record, say
>
> User A in program P
> Begin transaction
>
> A little time later
> User B in program P
> Begin transaction
>
> Then user A inhibits user B from going further until transaction A has been
> completed.
Not with multi-versioning. Please see the link below for details:
http://www.postgresql.org/docs/postgres/mvcc.htm
Hope that helps,
Mike Mascari
