[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