Kevin Dangoor wrote:
I'm not sure what the status is of WSGI middleware and CherryPy, and how
easy they are to put together. Mostly in terms of configuring a stack
of middleware. But anyway, I posted a kind of scarecrow implementation
of this a while back:
http://blog.ianbicking.org/more-perfect-app-server-wsgi-transactions.html
Also, exceptions have to be raised all the way to this middleware for
the system to work.
Yes, I have a feeling that this would not be the easiest path to
implementation, for both of these reasons.
I think the decorator path is likely the easiest, *and* it potentially
allows someone to specify that no transaction is required for a given
method.
The method I gave does allow significant flexibility at runtime, in that
it merely calls certain methods at certain times; the logic is really in
the Manager class, and could support any number of kinds of
transactions. Well, not any number -- the Zope transaction manager
(mentioned in the comments on that post) handles two-phase commit and
some other fancy stuff. But anyway, the middleware really just ensures
certain boundaries for a transaction (bounded by the request itself), if
you add the transaction to the middleware. I.e., a transaction added to
the middleware must be rolled back or committed by the end of the
transaction, with certain defaults in the case of a successful or
unsuccessful request.
Irregardless of the way transaction boundaries are determined --
middleware or decorator (both of which are very similar in both function
and implementation, just applied at different stages) -- the possibility
of a generic manager should be considered, that can manage a variety of
transactions (both in SQLObject or elsewhere).
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
