[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnumed-devel] re: non-serializability detection
From: |
catmat |
Subject: |
[Gnumed-devel] re: non-serializability detection |
Date: |
Tue, 18 Jan 2005 01:36:12 +1100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041231 |
This is about gmPG, gmBusinessObject.
when a medical record is opened, are long running transactions kept open ?
(e.g. for each group of tables, references belonging to the same concept,
is a transaction commenced when the values are read in to the dbobjects).
Otherwise, in a commit of an update on an old value, would checking
a timestamp or sequence number be needed ? ( redundant application
timestamp ordering,
because sql transactions aren't being used across whole life of dbobjects).
dbobjects seem to be checked out in one transaction, held for some time,
and then
checked-in in another transaction, and serializability is only an issue
if someone else
is checking out or checking in during the short time of the checking-in
transaction.
But actually, the transaction should run from when the dbobject is
checked out to when
it's checked in, if the in-built sql transaction mechanism is to be used
for serializability enforcement,
and preventing lost updates. This would chew up connections , because
transactions seem to
be associated 1-1 with connections.
So application transaction checks might be needed, either application
locks or timestamps
held , checked and updated at the server when dbobjects are created or
completed, in order to
abort or warn against a lost update.
SQL transactions currently seem only useful for maintaining referential
integrity.
(probably wrong, but it helps to clarify this).