[PEAK] storage.autocommit

[Phillip J. Eby]

At 03:11 PM 3/12/05 -0800, Dave Peticolas wrote:
>I think the Autocomitter and Untransactable classes
>have an extraneous self argument in the 'super' calls
>of their init methods.

Looks like you're right.  That module was written before I became "test 
infected", and isn't really used in PEAK at the moment, so it's nor 
surprising that it doesn't actually work.  :)


>Also, a question: is Autocommiter intended for use as
>a mix-in with existing data managers?

I'm not aware of any sane uses for autocommit on a data manager.  :)

Autocommit is basically a PEAK pattern for dealing with resources that 
can't be managed in a transactional way, or to have methods that execute in 
a transaction of their own.

For example, sending mail to an SMTP server isn't transactional, as once 
you get to the DATA, you can't roll back.  Updating a file in place is 
similarly untransactable, short of copying the file first.  So, for 
interfaces to things that are sometimes transactable and sometimes not, 
PEAK uses an 'autocommit' idiom, where an application can specify that 
autocommit behavior is desired.

Actually, it's not so much a statement that the behavior is desired, it's 
more an explicit authorization to *allow* autocommit behavior, so that a 
program in a transaction doesn't accidentally do something untransactable.

There is also another use case for autocommit that Ty and I call "side 
transactions".  For example, you may have an error handler that sends an 
email to a system administrator.  Normally, a transactional mail-sending 
component would use the transaction service in the surrounding service 
area.  However, by creating such a service with the autocommit flag set, 
then the AutoCommitter mixin creates a private transaction service 
exclusive to that component, and then any autocommitted methods will be 
wrapped in the private transaction, separate from the "main" transaction 
(which is probably aborting because of the error we're trying to report via 
e-mail).

Does that make more sense?  Anyway, there's not much call for using this 
with a DM, because it's the individual methods that have to be wrapped in a 
transaction for the autocommit stuff to be meaningful.  If you want a DM to 
have its own transaction service, it's easy enough to set that up using 
normal PEAK component configuration.