[Seaside] Transactions, database connections, indices,
GOODS and Seaside
Julian Fitzell
julian at beta4.com
Thu May 13 19:47:38 CEST 2004
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.
Julian
More information about the Seaside
mailing list