[Zope-DB] Avoid Lost Updates?

[M.-A. Lemburg]

Martin Gebert wrote:
> Hi all!
> 
> I didn't found much about this issue, so I'd like to ask this list. 
> Please correct me if I'm stating anything wrong...
> 
> Zope provides transaction management for RDBMS bound to it's internal 
> transactions - begin and end of a TA are marked by Request and Response 
> (request for the page until end of uploading it). This surely is a 
> convincing and quite secure concept, working for the most practical 
> purposes.
> The problem is how to manage longer transactions which spread over two 
> or more requests, esp. in combination with locking? Locking is bound to 
> commit/rollback cycles, too.
> 
> The problem I face is the following:
> Consider a person retrieving his personal data from an RDBSM 
> (MySQL/InnoDB) via Web (Zope) to change it. After that he presses the 
> submit button to write the data back.
> If this person takes a while for entering, and some other person (e. g. 
> with a manager role) changes his data in the meanwhile and saves 
> *before* the other one, this update will be overwritten with the update 
> of our first person and is simply lost.
> Doing an exclusive lock ("for update") on retrieving isn't of much use, 
> for the lock will be set back at the moment the result page was sent to 
> the client; the transaction is at it's end there and a new one begins, 
> ending with sending the updated data back to the DBMS (or cancelling the 
> process).
> 
> I know this is an old problem, and due to the statelessness of the HTTP 
> protocol. But I've already seen a Zope site which was trying to keep the 
> Request up until the submitting of the site, which showed as a 
> neverending retrieval of the page (the "Loading..." sign in the browser 
> didn't stop until you either hit the "Stop" button, went to another 
> page, or pressed "Submit").
> 
> My question is:
> Is there any way in Zope to extend TAs over a couple Requests, e. g. to 
> keep the Request open as described above? Is this a practical solution, 
> and what are the problems (there are at least timeout issues)? May there 
> be a solution which is based on the DBMS (ignoring commits to keep the 
> TA open)??? Or is this one of the long-known-and-so-far-unresolved 
> problems of Web programming?
> 
> Thank you for reading that far!

Why don't you save the data and the locking information in a
persistent user object and only write the new data to the database
when the user has finished working it ?

(locks should have a timeout builtin in order to avoid deadlocks
if the user never gets to the finishing state)

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
_______________________________________________________________________
eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,...
Python Consulting:                               http://www.egenix.com/
Python Software:                    http://www.egenix.com/files/python/