You are now biting off quite a bit. This is the generic problem that
all database systems have to do to handle transactions.
I believe that this will increase the deadlock possibilities. Without
a transaction, it might have been possible to get in and out of a subroutine
without holding the lock except within the subroutine.
With a transaction, all variables touched within the dynamic scope of the
transaction will have to be locked.
<chaim>
>>>>> "KF" == Ken Fox <[EMAIL PROTECTED]> writes:
KF> I was thinking about this same problem while reading RFC 130. It seems
KF> like transactions and exceptions are closely related. Should we combine
KF> the two?
KF> try transaction {
KF> ...
KF> }
KF> That's a really interesting extension to exceptions -- code that has
KF> no side-effects unless it finishes. BTW, how useful are transactions on
KF> internal variables if we don't provide I/O transactions too?
KF> Since the "transaction" keyword can only appear after "try", it
KF> doesn't have to appear as a new global keyword.
KF> This type of language feature strikes me as something similar to the
KF> Pascalish "with" proposal -- the "transaction" keyword triggers munging
KF> of the variables used in the following block. Obviously the munging
KF> is very different between these, but if we allow the general concept
KF> of munging the intermediate code (parse tree or OP tree or whatever),
KF> then both "with" and "transation" might be implemented from user code
KF> outside the core.
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
