[Seaside-dev] retry actions cant reach session

Sebastian Sastre ssastre at seaswork.com
Wed Mar 11 12:23:54 UTC 2009


Ok, as filters can't retry by design I've followed back to get where I can
retry. 
I've found this works just fine:

XXDatabaseSession>>handleRequest: aRequestContext
	self maxRetries timesRepeat: [
		(aRequestContext 
			push: self 
			while: [self filter responseForContext:
aRequestContext]) ifNotNilDo:[:response|
				^response].
		(Delay forMilliseconds: 200 atRandom) wait].
	self error: 'Could not resolve some transactional conflict: Please use
back-button of your browser and try again.'.
 

where XXDatabaseSession is a subclass of WASession. I know that is disencouraged
but I don't see alternatives. I'll very much prefer to have all the database
responsibility in one place: all in a session subclass or the filter. But
without the capability of retries it has no sense to use the filter for ACID
transactions.

sebastian




> -----Mensaje original-----
> De: seaside-dev-bounces at lists.squeakfoundation.org 
> [mailto:seaside-dev-bounces at lists.squeakfoundation.org] En 
> nombre de Sebastian Sastre
> Enviado el: Tuesday, March 10, 2009 19:05
> Para: 'Seaside - developer list'
> Asunto: [Seaside-dev] retry actions cant reach session
> 
> hi there,
> I'm debugging right now (no solutoin yet) an issue about not 
> having the session
> reacheable when retrying an action of the app.
> 
> As you may know transactions are to solve concurrence so when 
> sh*it happens you
> just retry the action.
> In seaside 2.8 that is handled perfectly well in ODBSSession. 
> It does that by
> handling a series of database exceptions in which you make 
> the thing just to
> retry. After N retries the thing gives up and complains to the user.
> 
> With 2.9, in the filter, I'm trying to achieve the same. The 
> problem is about
> components that are reaching the current request context but 
> it's returning nil
> when they ask for the session.
> 
> Please correct me if I'm wrong but action retries in the same 
> request where not
> taken in mind while designing request handling in seaside 
> 2.9. So I'm starting
> to be nostalgic about the simplicity of WACurrentRequest.
> 
> I don't get when/where the request context start to know the 
> session. Any
> pointers to clarify/solve this will be very much appreciated,
> thanks,
> 
> sebastian 
> 
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev



More information about the seaside-dev mailing list