[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