[Seaside] Re: Application/Session Objects
dev at archonet.com
Wed Feb 22 21:32:49 UTC 2006
Yanni Chiu wrote:
> 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.
Good - sounds like what I'll need.
> But you still need to get a connection from somewhere.
> The choices seem to be:
> 1. the session holds it
Session is the wrong boundary for me (or at least isn't right all of the
> 2. it's gotten from a pool for each transaction
That's what I'm trying to do.
> 3. a new one is started for each transaction (possibly
> using pgpool).
> Is #3 what you mean by "connection pool seems excessive"?
Yep. If I'm running pgpool and memcached anyway then I'll go back to PHP
or Perl - I've got plenty of libraries to do form building/validation there.
> 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.
I'm not saying the http req/response is the right option for all
occasions, but then neither is the session - I'm trying to decouple the two.
Hmm - practical example: An update query might fail. I want to do two
1. Log the error to the database application_log table. I'll do this as
step 1 because I don't know if step 2 will succeed.
2. Recover from/correct the error.
At this point I need *two* connections for this one req/response, and
connection #2 could span multiple req/response if I needed it to. I've
had to do something similar to this in PHP (and work around a bug in the
libraries while doing so).
Does this make sense, or am I approaching it the wrong way for an
object-oriented persistent framework?
More information about the Seaside