> 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.
> I *think* the above construct clearly supports the two distinct exit
> states. Is there something else I'm missing?
Except for the race condition that Guido points out, it's useable. I
guess Guido's syntax would be sufficient after all:
locking object:
object.success = 0
# stuff
object.success = 1
It would get somewhat more complicated with nested locking: statements
on the same object, though, since the "success" member would have to
become a stack (or equivalent).
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?
Guido?
-- Ty Sarna "Don't be wet or humidity, for the cause of tsarna@endicor.com electric obstacle." -- Warning from a manual