[Zope3-dev] ZopePublication performs auth outside transaction

[Jeremy Hylton]

On Wed, 2003-04-23 at 12:36, Phillip J. Eby wrote:
> Another thing that suggests it's a hack (or at least that the policy has 
> outlived its usefulness): the recent suspend() and resume() don't make 
> sense except in the context of a fixed policy for threaded 
> transactions!  If you aren't required to have a singleton transaction per 
> thread, there's no need to "suspend" one; just stop working on it and use 
> another one.
> 
> So, at the least, suspend()/resume() appears to me to be a hack to work 
> around the fixed policy.  :)

The single-threaded transaction manager also supports suspend() and
resume().  They provide a way for suspending the current transaction and
resuming it later, regardless of how you determine what the current
transaction is.  It doesn't have anything to do with threads.

Use case: A server program executes transactions on behalf of clients in
response to RPC requests.  A single transaction can span multiple RPCs. 
The server uses suspend()/resume() to associate the action of a new RPC
with the proper transaction.  This is necessary in both a multi-threaded
server and a single-threaded, event-based server.

[Suggestion for expending the thread API]
> * Expose an API to create a transaction manager (in current ZODB4 parlance) 
> directly.

How about adding set_manager() to transaction.__init__?

This creates a module global with mutable state.  I don't like that too
much, but I really like the simplicity of get_transaction().  I'm can't
tell how much of a problem it would be if an application could only have
one transaction manager.  Hmm... I guess get_transaction() calls on the
default transaction manager, but there's no reason an application
couldn't interact with a manager explicitly if it wanted to.

> * Rename 'get_transaction()' to 'getDefaultTransactionForThread()' or some 
> such.  (Explicit is better than implicit.)

Yuck.  get_transaction() calls a method on the current transaction
manager, it's not specific to threads.

> * Have Zope use a placeful "transaction service" (with the publisher's 
> application object as its context); the default implementation of that 
> service could just call 
> 'getDefaultTransactionForThread()'.  (Alternatively, the "site" or 
> "application" object could supply a local transaction service so that 
> transactions are per-site.)

I'll leave that to a placeful expert :-).

Jeremy