On Jun 28, 2007, at 7:33 PM, Jonathan LaCour wrote:
>
> Alberto Valverde wrote:
>
>> I'd like to add here that I've got use-cases for the transaction
>> boundary and session initialization being closer to the server than
>> what the __before__ and __after__ hooks provide.
>>
>> For example, the authentication function I feed to AuthKit which uses
>> a DB connection to retrieve the user and it's associated roles and
>> permissions.
>>
>> I can think of other cases where other layers of middleware (more
>> precisely, Middleware FrameWork Components) might want to access the
>> database. Having all these layers plus the controller method (or
>> other
>> WSGI which sit below PylonsWSGIApp) wrapped in the same transaction
>> sounds like a good idea to me.
>
> Fair enough to all of the above, however all the feedback from Mike
> and
> Ian has made it clear to me that we need a few different things:
>
> 1. A standard transaction manager that can be plugged into any
> application, WSGI or not. It should be similar in scope and
> API
> to Zope's transaction manager, but free of Zope dependancies.
>
> 2. A piece of middleware that uses the transaction manager to
> rollback
> any active transactions in the case of an exception, or commit
> them
> in the other case.
(I'm assuming this middleware above the PylonsWSGIApp...)
>
> 3. Either some middleware or just a few lines inside the
> BaseController
> of the TurboGears template that starts a transaction on every
> request and puts it into the transaction manager.
Hmmm, wouldn't having two transaction boundaries at 2 and 3 be
redundant? Or maybe both boundaries will use the same manager in a
similar way paste.registry has only one Registry for the whole stack?
(albeit different context boundaries every time a RegistryManager is
stacked)
One problem I see is that this might cause trouble in cases like this:
Request
|
V
db transaction middleware -> creates session A
|
V
authentication middleware -> authenticates user and keeps ref to User
instance (attached to session A)
|
V
other middleware and PylonsApp
|
V
TG controller -> creates session B inside __call__
|
V
authorization library tries to check permissions for mapped Foo
instance (attached to session B) which has a owner attribute:
foo.owner (sess B) == logged_in_user (sess A)
I haven't actually tried it so I'm not sure how to objects attached
to different sessions compare as or interact, so this might be a non-
issue (maybe Mike can shed some light on this?)
Anyway, this might be a non-issue on the whole if the transaction
middleware does not handle session creation at all.
OTOH, I do see the difficulty of having just one boundary in a single
TG/Pylons app in a layer of middleware above PylonsApp since I don't
see a clear way of making parameters passed via a decorator reach the
middleware *before* the method is actually called (which will be
needed to signal that a BEGIN should not be issued)
Alberto
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
