[Seaside-dev] retry actions cant reach session

[Julian Fitzell]

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
>