[Seaside] Re: Application/Session Objects

[Richard Huxton]

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 
time).

> 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 
things:
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?
-- 
   Richard Huxton
   Archonet Ltd