[Seaside] Re: Application/Session Objects
yanni at rogers.com
Wed Feb 22 21:05:16 UTC 2006
Richard Huxton wrote:
> Julian Fitzell wrote:
>> 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.
> That's the sort of thing. A separate connection-pool seems excessive
> since I have persistence of state available anyway.
If you use the technique in ODBSSession in the code pointed at
in Julian's link below, then you have what you need to wrap an
http req/resp in a tranaction.
But you still need to get a connection from somewhere.
The choices seem to be:
1. the session holds it
2. it's gotten from a pool for each transaction
3. a new one is started for each transaction (possibly
Is #3 what you mean by "connection pool seems excessive"?
>> 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.
I don't wrap my transactions at the http req/resp boundary.
I put it at the boundary between the UI and the domain logic.
So, in addition to CRUD operations (Create/Read/Update/Delete),
I have operations like "parse and load invoice",
"create contract from initial invoice", "delete entire contract"
and "audit invoice against contract", which are transactional.
It seems to me that using the http req/resp as a transaction
boundary is an unnecessary and potentially limiting constraint.
But as a first cut, just go for it.
More information about the Seaside