> Jim Fulton:
>> I would like to have something similar, but I can live without it.
>> It would be useful for some applications (other than TP) to be able to
>> control when (and even if) the suite is executed. When I first
>> suggested this, my thought that, to justify changing the language,
>> the mechansism should be very general. My thought was to give a way
>> to implement almost any sort of application-defined control
>> structures.
> But surely for that you would also have to have a way of introducing
> arbitrary syntax -- there's no reason why an application defined
> control structure would only require a single block. Again, let's put
> this sideline to rest until there's time for some later time.
Fair enough.
> And in a later message:
>> Drats, I spoke too quickly. I see a problem with 1. Consider the
>> following __enter__:
>>
>> def __enter__(self):
>> try:
>> self.begin()
>> except:
>> self.abort()
>>
>> Suppose an interrupt causes an exception to be raised just after
>> executing the try statement. __leave__ will not be called and the
>> transaction created in the above try statement will not be aborted.
>>
>> I think that __enter__ and suite need to be treated as a unit and that
>> __leave__ should be called even if an exception is raised in
>> __enter__. Is it possible for an exception to be raised *between* the
>> call to __enter__ and the execution of suite?
> This is indeed a problem, and this is why I proposed to let __enter__
> return an object whose __leave__ method is to be called. The object
> returned can then have a destructor (__del__ method) which aborts thr
> transaction if it has neither been committed nor aborted.
Hm. I wonder if object destruction is deterministic enough to make
this work. Do you guarantee that an object created but not returned
from a function (due to an exception) will be destroyed before any
subsequent code runs? It is critical that if an exception occurs in
__enter__ (or after calling __enter__ but before calling suite) after
creating a transaction, that the transaction be aborted before any
subsequent computation takes place. Given comments I've read about
the non-determinism of garbage collection, I am reluctant to rely on
it for transaction management.
Is there some problem with calling leave even if an exception is
raised in __enter__, or between completion of enter and execution of
suite? Something like:
try:
object.__enter__()
...execute suite...
except:
object.__leave__(exc_type, exc_value, exc_traceback)
else:
object.__leave__(None,None,None)
> Don't similar race conditions exist in your original proposal?
I don't think so. In my proposal, the transaction initialization code
and the transaction suite are executed in the same try suite, so any
exception raised after the creation of a transaction but before
transaction completion is caught. In the current proposal, I think
that this could be handled by always calling __leave__.
--
-- 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.