[ZODB-Dev] ZEO and commits

Christian Robottom Reis kiko at async.com.br
Tue Oct 28 12:22:31 EST 2003


On Tue, Oct 28, 2003 at 05:16:46PM +0100, Antonio Beamud Montero wrote:
> A create a X object, make changes in it, commit every few actions and
> his process time is very long (around 1 hour).
> B can call the cancel method in that X object in a asynchronous way. The
> code of method cancel_request in the server is like:

If B calls cancel during the time in which A is modifying X, then you
*will* have a conflict, and one that I don't think _p_resolveConflict is
going to be able to fix. In other words, one of the two is going to lose
work.

>      cancel_request(self, id):
>        con = self.db.open()
>        con.sync()
>        root = con.root()
>        if root['pendings'].has_id(id):
>            req = root['pendings'].get(id)
>        req.cancel()
>        get_transaction().commit()
> 
> With this I want to change the internal value of the variable _cancel,
> then, in the A process, in one checkpoint inside the code I abort
> transaction well done.

The A process will have to keep an eye out if X has been cancelled, by
calling sync() before it wants to commit (while storing a copy of its
changed data -- maybe you can use the pickle.loads(pickle.dumps(object))
trick to store this copy). If it hasn't been cancelled, then it should
move its data from the copy into the real object, and then commit. You
still have a locking issue, but the chance is reduced because A holds
dirty data for a shorter time. If conflicts happen, you'll have to abort
(and tell the user that somebody else cancelled X while he was
committing).

Take care,
--
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331



More information about the ZODB-Dev mailing list