> jfulton@dsjfqvarsa.er.usgs.GOV (Jim Fulton ) wrote:
>>
>>
>> I am looking at the use of nested transactions for distributed object
>> programming in Python. (This is based on the models given in "Atomic
>> Transactions", by Lynch, Merrit, Weihl, and Fekete.) In implementing
>> nested transactions in python, I find that I would like to be able to
>> use a syntax like:
>>
>> transaction:
>> # some code
>> # that makes up the transaction
>> transaction:
>> # This is a sub transaction
>> # Perhaps more code for the first transaction
>>
>> the idea being that transactions hava associated blocks of code. If a
>> block executes completely, then the associated transaction commits.
>> If an exception is raised, then the the transaction aborts and
>> propigates the exception. If a transaction, aborts on its own, it
>> raises an abort exception.
>>
>> It appears that without something like the above capability,
>> implementing nested transactions is surprizingly ugly. This is due to
>> the fact that I need to closely tie the initiation and completion of a
>> transaction. Without an automated (i.e. language-supported)
>> mechansism, I have to resort to either inelegent or unreliable
>> mechanisms involving explicit user-supplied transaction commits.
>> These user-supplied commits will have to name the corresponding
>> transaction, requiring the management of additional variables to hold
>> the transaction information.
> As i see no meaning for interleaved transactions i can see no use of
> using t1 and t2 (except to ensure destruction and thus rollback of
> transactions when they go out of scope (or some time later))
We are talking about nested, not interleaved transactions.
Actually, I want transactions to commit at the end of a block. They
should abort if an exception occurs, and, of course, they may abort
for other reasons.
My example would have been a little more interesting if written like:
transaction:
# some code
# that makes up the transaction
transaction:
# This is a sub transaction
abort:
# Some code to "recover from the abort",
# Perhaps more code for the first transaction
> Is'nt the same easily written like this using a Transaction object
> with methods for keeping a stack of nested transactions
> from transaction import *
> Transaction = transaction(ThingThisTransactsOn)
> try:
> Transaction.Begin()
> # some outer transaction code
> try:
> Transaction.Begin()
> # do the sub-transaction stuff here
> Transaction.Commit()
> except (AnyButBeginOrCommitError):
What is AnyButBeginOrCommitError?
> Transaction.Rollback()
> # some other cleanup
> # some more outer transaction code
> Transaction.Commit()
> except (AnyButBeginOrCommitError):
> Transaction.Rollback()
> # some cleanup for failed outer transaction
> # some non-transactional code (is there actually any? :)
I started out with an aproach like this. The trouble is, the
transaction boundaries are not directly connected to the control flow.
If the user forgets a Transaction.Commit(), or control transfers
around a Transaction.Commit(), then the next Transaction.Commit() will
commit the wrong transaction.
> aren't transactions just one kind of exception handling anyway?
They are closely related. This is why I want to be able to tie them
in with the control flow.
> perhaps we can make it into:
> try(Transaction): # implies Transaction.Begin(), and
> # Transaction.Commit() on success/no exception
> #some transaction code
> try(Transaction):
> # do the sub-transaction stuff here
> except (Any): # implies Transaction.Rollback() for inner trx
> # some other cleanup
> # some more outer transaction code
> except ():
> # some extra cleanup for failed outer transaction
> # some non-transactional code (is there actually any? :)
I considered suggesting try, and try might be a good choice for
transactions, but I wanted to propose a general mechanism that would
work for other situations as well. The try statement is loaded with
semantics, that might not make sense in a more generalized mechanism.
--
-- 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.