[Persistence-sig] Threads and transactions (was Observation API)

[Phillip J. Eby]

At 04:55 PM 7/30/02 -0400, Shane Hathaway wrote:
>On Tue, 30 Jul 2002, Phillip J. Eby wrote:
> >
> > By the way, I'd still like to have the option of having participants join a
> > transaction "permanently", in order to avoid all of the state management
> > code that such things currently require.
>
>Yes, that sounds useful for logging, periodic backups (to ensure the
>backup is based on fully committed data), and other utilities.  As long as
>joining permanently is optional, since objects like CommitVersions don't
>need to stick around.

Also, in my use cases, certain caches want to clear themselves on 
transactional boundaries.


>Now, I wonder about multithreaded apps.  If you join a transaction
>permanently, do you join all threads?  At first I wasn't thinking you
>would, but on further reflection, it seems like that's what you'd want.
>And how would this affect CORBA (since, from what I hear, its transactions
>are not bound to threads)?

A permanent join should be to *that* transaction object only.  Anything 
else implies too much policy, IMHO.  For my use cases, I will normally have 
at most one transaction per thread.  This is the normal use case for Zope 
also, I believe.  In the event that you have an object which can safely 
participate in multiple transactions simultaneously, then by all means you 
should be able to register it with them.

I think that the transaction API *should* provide at least some nominal 
support for associating a transaction with a thread, or automatically 
creating per-thread transactions, if only because ZODB has supported that 
in the past.  Java's JTA also assumes that the default use case is 
transaction-per-thread.

But, the minimum I would like to see is that a transaction object should be 
reusable over and over.  As long as that's the case, a permanent join is 
useful, since I can declare a transaction object, associate things with it, 
and proceed about my business.

I think most people, however, will want to be able to do something similar 
to ZODB's existing "get_transaction()" function to get a singleton 
Transaction object, to do basic single-threaded, single-transaction 
applications.  And simple things should be simple.