>>>>> "KF" == Ken Fox <[EMAIL PROTECTED]> writes:
KF> Chaim Frenkel wrote:
>> You are now biting off quite a bit.
KF> What good is half a transaction? If transactions are to be useful,
KF> they should be fully supported -- including rolling back stuff some
KF> third party module did to its internal variables. (Maybe that's a
KF> little extreme ;)
Definitely, especially if the third party already wrote something into
a file or sent it out over the network.
>> 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.
KF> Dead lock detection? Throw an exception and re-try the transaction?
You haven't handled the problem of external changes. re-trying may
not be a valid option.
KF> I don't think there's any good answer for this. Joe Programmer must avoid
KF> shooting himself in the foot. (BTW, if there's a possibility for deadlock
KF> with a transaction, there's the possiblity of data corruption without
KF> a transaction. I don't think transactions increase your exposure.)
Hmm, ...., no, a transaction needs to hold the locks longer. A
non-transaction version would simply lock the variable until it was done.
Different problem space.
<chaim>
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
