[Zope3-dev] ZopePublication performs auth outside transaction

[Phillip J. Eby]

At 11:55 AM 4/23/03 -0400, Jeremy Hylton wrote:
>On Wed, 23 Apr 2003 11:45:41 -0400
>  "Phillip J. Eby" <pje@telecommunity.com> wrote:
> > At 09:08 AM 4/23/03 +0100, Chris Withers wrote:
> > >Phillip J. Eby wrote:
> > >>I also wonder if maybe there should be a placeful
> > Transaction service replacing the "get_transaction()"
> > hac^H^Hook.  :)
> > >
> > >Surely you mean placeless?
> >
> > Absolutely not.  What if I want to write a thread-free
> > reactor-based Zope app using Twisted?  Associating
> > transactions with threads is a hack.
>
>Associating transactions with threads isn't a hack.  It's a
>policy, and one a reasonable one for lots of applications.

I didn't mean to say it wasn't a very useful hack.  ;)  It has worked quite 
well for me and many others for many years.  But the whole point of the 
Z3CA, as I understand it, is to make all system policies 
replaceable.  Therefore, a fixed policy seems like a hack.

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.  :)


>There's a single-threaded transaction manager in the
>transaction package, too.  We just don't have a mechanism
>to allow an application to change the policy.  Suggestions
>on an API are welcome.  The API should not be tied to Zope,
>since it's in the transaction package.

Here's my suggestion:

* Expose an API to create a transaction manager (in current ZODB4 parlance) 
directly.

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

* 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.)

By default, everything would work as it does now, but applications that 
manage place-specific transactions can create transactions and manage them 
explicitly, whether they use Zope or ZODB.

One other use for this is to supply an alternate transaction 
implementation, such as one that allows cascading updates between data 
managers.  ;)