[Seaside-dev] filters initialization with request context?

Sebastian Sastre ssastre at seaswork.com
Sun Mar 8 03:30:44 UTC 2009


Update on this problem. 

the database pool receives aBlock and it will evaluate the things of the app in
the continuation.
So in the pool I make something like:

	[aBlock evaluateIn: aTransaction] ensure:[ aTransaction commit]

and aTransaction goes and try to commit but all its instVars are in nil. 
Is this a continuation effect of not copying those after evaluating aBlock? how
would you do something like this?
thanks
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: Saturday, March 07, 2009 19:01
> Para: 'Seaside - developer list'
> Asunto: RE: [Seaside-dev] filters initialization with request context?
> 
> > Normally you should be able to access the current request 
> context when
> > the filter is initialized.
> > 
> that sounds good but I'm not able to reach it. I mean a 'self 
> requestContext'
> while #initializeFilters is signaling.
> Could be me using a wrong version of seaside 2.9a2? 
> I've loaded 2.9a2 from the script made by the site (all but tests)
> 
> > It shouldn't be necessary to subclass WASession in Seaside 
> > 2.9 anymore.
> > 
> I was guessing that but well, I'm migrating one feature at the time :)
> 
> a weird thing I'm seeing right now is that sometimes I get 
> more than one
> transaction executed per request. I'm still investigating yet 
> but seems to me
> like some ensure: could be unwinding more than once. 
> 
> Please correct me if I'm wrong but AFAIK Seaside uses 3 
> requests at the begining
> and then 2 (a redirect and the request/response). So once 
> session is started, it
> should be commiting "twice per click" (unless redirect can be 
> made outside a
> transaction which is an optimization I didn't investigate yet).
> 
> What I see here is that after getting a proper result, 2 o 4 
> additional commits
> are made for the same (already responded) request. That, at 
> some point, ends up
> making things get lockes and sh*t like that :P
> 
> Is anybody working with a transaction filter and see things 
> like that? 
> 
> thanks,
> sebastian
> PD: I'm using OmniSupport + an upgrade patch I've made.
> 
> > Lukas
> > 
> > -- 
> > Lukas Renggli
> > http://www.lukas-renggli.ch
> > _______________________________________________
> > seaside-dev mailing list
> > seaside-dev at lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
> 
> _______________________________________________
> 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