[TransWarp] __getitem__ on DM requires active transaction

[Phillip J. Eby]

At 02:55 PM 12/23/02 +0200, Roch'e Compaan wrote:
> > >I actually want the cache to be flushed between transactions - I just
> > >didn't think object retrieval required a transaction and it seems quite
> > >tedious to manually start a transaction whenever I want to
> > >retrieve something whereas "save", "new" and "delete" operations can
> > >automatically start a transactions.
> >
> > No, they don't.  If you want transactions, you have to start them.  PEAK
> > requires you to be explicit on this point in order to avoid programmer
> > error.
> >
>
>No, they don't  - I meant to say "can potentially". I was thinking that
>create/delete/edit operations on objects can either cause the
>DataManager to start or join a transaction without the programmer having
>to worry about it at all. I realise now that this can only work if I
>have a single transaction for the whole app or if there are logical
>start and endpoints for a transaction like a web request and response.

Nope.  The programmer *has* to care about transactions, and PEAK is 
specifically set up to force you to care.  :)  Of course, as you say, the 
exception is a web hit, and that's easy to handle in that context, because 
it's a "container" issue.

Now, that's not to say that you can't or won't use the Autocommit 
tools.  For example, you could subclass DM, mix in Autocommit, and then 
define some methods on it that are "autocommitted".  Such methods can 
manage their own transaction scope, if and only if the DM is created with 
its autocommit mode engaged (which causes the DM to allocate its own 
private transaction object).  Such use cases are pretty specialized, 
however, like the previous examples on this list of sending an error 
message via e-mail.

By the way, most of the existing DM methods are not suitable for 
autocommit, because they aren't something that you could meaningfully do as 
the entire content of the transaction.  An autocommit method needs to 
encapsulate an entire transaction in itself.

Actually, what's kind of interesting about the web request and response 
example, is that you could define your web request objects as Autocommit 
and their "process" or "publish" methods as autocommitted, and it would 
handle that use case rather nicely.