Re: [Gnumed-devel] re: timeout instead of blocking

[Ian Haywood]

catmat wrote:
  A solution might be to have 2
> connections per client,
> one for doing  reading and writing, and one for message listening ( 
> assuming the
> pypgsql blocking listen command works).
Actually we have 3: reading, writing and listening.
>     Then in the case above, when A commits , it issues a notify "message",
> the listen channel on B's client gets the notification, and then B's 
> client aborts its transaction,
> begins a new transaction and re-reads, including A's changes. Now when 
> it tries to write x
> after reading it , it has no problems, because it has seen A's x.
Yes.

> BTW , the above isn't necessary to know  with the current  scheme to use 
> xmin to detect
> changes between read and write transactions  .
Yes.

It depends on whether you want to know of concurrency problems when they happen
(so a gnumed client reacts as soon as someone else commits changes) or when you
try to commit (and find XMIN as been changed behind your back).

Personally I think 2/ is functionally better.
> ( it just seems untidy to have to do your own concurrency checking with 
> timestamps , using a timestamping transactional database system).
Where are the timestamps??
This concurrency checking is "supra-transactional": XMIN is the *transaction 
number*
        A reads some data (XMIN=1)
        B reads some data (XMIN=1)
        B writes some data (XMIN=2)
        A writes some data (XMIN=3)

The alternative is a "long transaction" that lasts as long as we have the 
patient's file open,
but this has another problems (such as, if we crash, we lose all changes)

Ian

signature.asc
Description: OpenPGP digital signature