[Seaside] Transactions, database connections, indices, GOODS and Seaside

[C. David Shaffer]

Avi Bryant wrote:

>
> On May 13, 2004, at 5:24 PM, C. David Shaffer wrote:
>
>> Thanks guys.  I'm using GOODS right now and each session registers 
>> the active DB in a dynamic variable during request processing.
>
>
> I'm not sure what your usage patterns are for GOODS, but unless you're 
> opening a new connection for every request (which would be pretty 
> inefficient), I don't see why this wants to be a dynamic variable - 
> any given session should always use the same connection.  You might be 
> able to share one connection between several sessions, with 
> appropriate mutexing, but I definitely wouldn't want to switch 
> connections halfway through a session, because the object identities 
> would be all wrong.  Or am I missing something?


I hadn't thought it through.  This pattern works for RDBMS's but there 
"identity" has a different meaning.  Gemstone supports multiple 
transactions on a single connection and would migrate objects from one 
transaction cache to another as needed.  When I did use OmniBase in a 
web app I used wrappers to migrate objects from one transaction to 
another (I'd hold on to the object ID and load it whenever the 
transaction changed).  This was less than ideal but it seemed the 
natural progression of what I had been doing for years.  As you said, if 
I limit the number of active transaction by serializing access to a 
pool, I should be OK to map a session onto a single transaction.  Thanks.

>
>>
>>    ^SCCurrentTransaction
>>        use: (1 to: 100) atRandom
>>        during: [super responseForRequest: aRequest]
>>
>> but this code only results in a single value for SCCurrentTransaction 
>> for each session.  Why is that?  It certainly doesn't fit with a view 
>> of dynamic scope sans continuations.  Is this a subtly caused by 
>> continuations or error handling that messes up the dynamic binding 
>> mechanism?
>
>
> It's a subtlety of continuations.  You will probably find that it 
> isn't exactly one value per session, but rather per component or task 
> - a #call: is likely to change the value.  This makes sense if you 
> think about it - you have to be using the same stack for the duration 
> of a task's #go method.  There's a new call to #responseForRequest: 
> every time, of course, but then you jump back into the old stack.
>
> It's an interesting point, though, and one I hadn't fully thought 
> through until now.  I guess it means that the correct pattern for 
> dynamic variables is to store them in the session, and then have 
> something like:
>
> SCCurrentTransaction class>>value
>     ^ WACurrentSession value currentTransaction
>
> It may be worth making that a standard part of Session... 


>
> Cheers,
> Avi
>
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/seaside