[ python-Bugs-1000693 ] Interrupt safety

[noreply at pgfoundry.org]

Bugs item #1000693, was opened at 2006-07-28 09:46
You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1000693&group_id=1000094

Category: PQ/PQueue
Group: To do
>Status: Closed
>Resolution: Accepted
Priority: 4
Submitted By: James Pye (jwp)
Assigned to: James Pye (jwp)
Summary: Interrupt safety

Initial Comment:
Currently, if an exception(keyboardinterrupt, etc) is raised while state is being changed, the state effectively becomes corrupt. No attempt is made to keep things in order. The problem here is that interrupts can occur at arbitrary times; making transactions interrupt safe would provide for a much more robust client.

Trapping signals in an application is the normal response here. However, considering this is a module that may be used in arbitrary applications, it doesn't seem to be an appropriate measure to take. Not to mention, it also [albeit, with some safety] assumes that no other kind of interruptions can occur.

The proposed solution is to apply some 2PC to client transaction objects themselves. Having a mechanism to validate that a message has been processed will allow client implementations to know whether to send the "current" message to the transaction again or to move on.

This will likely lead to a major change to how transactions work, but I doubt that any API changes will occur.

----------------------------------------------------------------------

>Comment By: James Pye (jwp)
Date: 2006-08-06 17:46

Message:
This is done. Tho, not without API changes. Some regressions performance-wise occurred, but the provided robustness is well worth it. Perhaps those regressions can be turned back at a later time.

----------------------------------------------------------------------

You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1000693&group_id=1000094