gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] gmObject problem


From: Horst Herb
Subject: [Gnumed-devel] gmObject problem
Date: Sat, 26 Oct 2002 14:21:34 +1000
User-agent: KMail/1.4.7

I have committed further changes; 
When a row is created new (instead of fetched form the backend), the new 
primary key is transparently created (save via the apropriate backend 
sequence),  the row is committed to the backend and the pgobject subsequently 
refreshed from the backend (how is this for comfort?).

This ensures that the pgobject state is consistent with the 
constraints/defaults imposed by the backend.

The big problem is:
If such an object would be part of an outer transaction (invisible to this 
object), and the outer transaction would be rolled back, this object would 
still remain committed - which would break integrity.

One way to solve this problem is creating a temporary "limbo" table flagging 
all OIDs of such risky transactions, such that the backend would roll back 
all committments that are flagged in limbo if the transaction "owning" the 
limbo key fails. Sounds like a lot of work... any better suggestions?

Horst




reply via email to

[Prev in Thread] Current Thread [Next in Thread]