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

C. David Shaffer cdshaffer at acm.org
Fri May 14 02:24:00 CEST 2004


Julian Fitzell wrote:

>
>
> Avi Bryant wrote:
>
>> Each Seaside session is guaranteed to only be processing one request 
>> at a time.  So you're actually perfectly safe to store the current 
>> transaction in the session for the duration of a request.  The best 
>> override point is probably #responseForRequest: - something like 
>> this, I guess:
>>
>> responseForRequest: aRequest
>>   currentTransaction := self newTransaction.
>>   [super responseForRequest: aRequest]
>>     ensure: [currentTransaction commit.
>>              currentTransaction := nil].
>>
>> There may be some subtleties here with error handling we'll have to 
>> work out (Julian?), but that's the basic idea.
>
>
> Yeah, that's pretty much exactly what we do, except that with OmniBase 
> it just looks more like:
>
> responseForRequest: aRequest
>     ^ [super responseForRequest: aRequest]
>         evaluateAndCommitIn: self database newTransaction
>
> This works fine until you start hitting concurrency problems.  You 
> don't want to have multiple sessions using the same OmniBase instance 
> when you start getting a lot of concurrent hits.  Bad news. :)
>
> And you don't want one OmniBase per session because the sessions could 
> hang around for quite a while and you never know when you can close them.
>
> So our solution was to create a connection pool.  Then our method 
> actually looks like:
>
> responseForRequest: aRequest
>     ^ self database execute: [super responseForRequest: aRequest]
>
> We have an omnibase support package with a few goodies in it that we 
> should get around to releasing.  I need to post our tutorial solutions 
> from StS as well, so maybe I'll see if we can get around to some of 
> that this afternoon or tomorrow.
>
> As Avi was hinting at, there is a problem with error handling in that 
> if you have walkback pages turned on and hit an error but don't debug, 
> the stack doesn't get unwound and you can end up with connections not 
> getting put back in the pool.  I sort of worked around it in the cases 
> where you've deployed and therefore turned off the walkbacks.  This 
> was in 2.3 and I need to double check what part of that fix we merged 
> into 2.5 at some point.
>

Thanks guys.  I'm using GOODS right now and each session registers the 
active DB in a dynamic variable during request processing.  I chose the 
dynamic variable approach since it allows my domain objects (which know 
nothing of sessions) to modify their indices.  I haven't load tested it 
but that will come soon.  Both Avi's and Stephen's dynamic variables 
worked just fine.  I went with Avi's in the end just to avoid a 
dependency on one more package.  Here's my code:


responseForRequest: aRequest
    ^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?


David




More information about the Seaside mailing list