[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] re: non-serializability detection
From: |
catmat |
Subject: |
Re: [Gnumed-devel] re: non-serializability detection |
Date: |
Wed, 19 Jan 2005 09:17:21 +1100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041231 |
Karsten Hilbert wrote:
when a medical record is opened, are long running transactions kept open ?
No. Unlocked transactions aren't of particularly great value.
For detecting concurrent updates, anyway.
Karsten
thanks, didn't follow up the original posting.
http://archives.postgresql.org/pgsql-general/2004-10/msg01441.php
wonder why no one responded, the need to do your own transactioning
ontop of the postgres transactioning for the class of applications where
transactions are interactive rather than batch seems an important issue.
Maybe postgres transactions should have a non-blocking option which
returns an exception instead of blocking on concurrent writing. That
would make maintaining long running transactions a more suitable
option for
interactive updates.
( Can anyone get set transaction isolation level serializable
to abort a concurrent write, instead of blocking ? Doesn't seem to work on
my postgres installation.)
using xmin as a transaction sequence number seems ok ;
the auditing function's audit id could also be used, because it's acting as
an object version id.
- [Gnumed-devel] re: non-serializability detection, catmat, 2005/01/17
- Re: [Gnumed-devel] re: non-serializability detection, catmat, 2005/01/18
- Re: [Gnumed-devel] re: non-serializability detection, catmat, 2005/01/18
- Re: [Gnumed-devel] re: non-serializability detection, Karsten Hilbert, 2005/01/19
- Re: [Gnumed-devel] re: non-serializability detection, Karsten Hilbert, 2005/01/19