[Seaside] Re: Application/Session Objects
julian at beta4.com
Wed Feb 22 18:55:34 UTC 2006
I think Richard's talking about having a pool of connections that are
given out as needed to individual sessions on a per-request basis.
Andrew and I did this on one of our projects and wrote the OmniSupport
package to help with this kind of thing.
Check out http://www.squeaksource.com/OmniSupport.html
Unless it's been changed, there should be a subclass of WASession that
will give you some idea where you need to plug in.
Yanni Chiu wrote:
> Richard Huxton wrote:
>> Hmm - that's useful, but what if I want to re-use the connection after
>> the request?
> I'm not sure I understand you. The connection is still open,
> and would be reachable via the session. Note that a WASession is
> longer lived than a single http request/response cycle.
> > That is, I'd like to be able to do:
>> 1. hook a request start, claim a DB connection from the pool
>> 2. do some database queries
>> 3. hook the request end, return connection to the pool
>> Crucially, #3 might restrict that connection for this session only or
>> allow any session to re-use it.
> Currently, for postgres, I connect with fixed (by configuration)
> username/password. Then, on the connection, I send:
> SET SESSION AUTHORIZATION username
> But I'm not entirely sure this the "right" thing, since I've
> not fully tested things with multiple users.
>> I'd hate to have an open transaction floating around for an hour while
>> I wait for the session to expire.
> Why would a transaction be open, unless you designed your
> application flow in that way. Normally, you'd accumulated
> user responses in your application model, through multiple
> interactions with the user. Then when they hit "Save", the
> transaction would be started, the database changes sent,
> and the transaction commited.
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
More information about the Seaside