[Seaside-dev] retry actions cant reach session

[Sebastian Sastre]

If I translate database responsability to a WASession subclass (as I use to had)
and ignore the comment in #handleRequest: which says not to override, then there
is no problem :)
Actually it's working quite well so far.
About the alpha, don't worry I know how much bleed I can bleed in this edge ;)
keep the good work and high design 
cheers
sebastian

> -----Mensaje original-----
> De: seaside-dev-bounces at lists.squeakfoundation.org 
> [mailto:seaside-dev-bounces at lists.squeakfoundation.org] En 
> nombre de Julian Fitzell
> Enviado el: Wednesday, March 11, 2009 10:51
> Para: Seaside - developer list
> Asunto: Re: [Seaside-dev] retry actions cant reach session
> 
> I'm a bit confused by what the problem is here because obviously the
> filters are called immediately after this method so it's hard to
> imagine why you can retry the request in one and not the other. That
> said, I'm not at all convinced that subclassing Session is a bad idea
> in general. There are times where a Filter makes sense, there are
> times where subclassing Application makes sense, times where
> subclassing Session makes sense, and times when subclassing a
> SessionContinuation makes sense. I certainly don't see Filters as a
> replacement for subclassing Session but they may be better solutions
> in some cases (maybe even in this case... I don't know).
> 
> But you are obviously still using alpha2, which is pretty different in
> a couple of respects here: the methods are #handle: and
> #handlerFiltered: and they don't return an instance of WAResponse, for
> starters. Given the number of issues you are having that we can't
> reproduce, I wonder whether you shouldn't wait until you can get the
> newest code loaded before spending too much time fighting with this.
> 
> Julian
> 
> On Wed, Mar 11, 2009 at 1:23 PM, Sebastian Sastre 
> <ssastre at seaswork.com> wrote:
> > 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
> >
> > _______________________________________________
> > 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