> Jim Roskind wrote:
>> I'm not sure I understand what you are trying to do, but *IF* I do,
>> then it is something I faced in dealing with recovery from loading
>> persistent objects (among other things). The strategy I took was to
>> slightly enhance what Guido suggested, and write code that looks like:
>>
>> object.__lock__()
>> try:
>> succeeded = 0
>> suite
>> succeeded = 1
>> finally:
>> if succeeded:
>> commit
>> else:
>> rollback
>> object.unlock()
>>
>> Is this what you are after?
> Yes (except for the race condition), but it's rather gross. Imagine
> writing a 3 or 4 level nested transaction that way... bleah! And the
> whole point Jim (the other Jim, who started this discussion) was getting
> at is that that kind of code is horribly error prone and hard to
> maintain, since code to implement it has to be duplicated everywhere
> it's used. What's needed is a way to take all the ugly guts above and
> factor them out into a single implementation in one class, plus a way
> to avoid the race condition. I think my "enter" scheme accomplishes
> that fairly well, as a minor rework of Guido's "locking:" idea.
Right.
As I point out in another message, other applications (such as
different transaction protocols) may have more conditions to check.
In the code above, there is alot of the implementation of the
transaction system hanging out. As someone putting together a
transaction processing system, I want to be able to hide many of the
details of the system for all of the reasons that one generally wants
to do implementation hiding, including those mentioned by Ty. I may
want to change how I manage transaction in the future, and I may want
to use a different transaction protocol from someone else.
> But as long as we're adding new syntax to Python, why not go the extra
> step to make it as clean and general as possible? Do you see any
> problems with my scheme?
I'd like to see something that is general enough to support a variety
of applications, not just those involving transactions and locking.
--
-- Jim Fulton jfulton@mailqvarsa.er.usgs.gov (703) 648-5622
U.S. Geological Survey, Reston VA 22092
This message is being posted to obtain or provide technical information
relating to my duties at the U.S. Geological Survey.