Questions about double (or more) request

The point is that, for every click you do, seaside run a continuation
it is identified by the  _s _f and  a number.

At this point when you assign a block to call back the block is
leads to the context, where count is a value x, eg 20

if you run  70 times the same continuation, count value will be the same 21  (20 +1).

because that,  Transcript show increase, increase, increase, renderContentOn and the count value is the same 21.

because that, fixtemp is very important in squeak, and Pharo have better behavior.

wich click is running all... but al run the same block

regard (sorry for my google english).

El 05/08/2009, a las 15:54, Diogenes Alberto Moreira escribió:

Bueno te lo contesto en castellano y despues trato de traducirlo. en otro mail (sorry for english speakers, my English is horrible)

El punto es este, por cada click que haces se ejecuta un continuation que esta identificado por el _s para la session _k para el componete un numero de &.
en punto que cuando vos le asignas un bloque al call back el bloque se lleva el contexto, donde count tiene un valor x, por ejemplo 20

por mas que ejecutes 70 veces, en el contexto del bloque count vale 20  e incease ejecuta count := 20 + 1.

por eso en el transcript, te aperece increase, incease, rendercontentOn y el valor que toma count es simpre 21. (para nuestro ejemplo). y por eso lo importante del fixtemp en squeak y la mejora que significo Pharo.

cual se ejecuta,,, todos.... pero todos hacen lo mismo...

Espero ser claro....

PD: mariano ponele onda y traducilo.

Saludos

El 05/08/2009, a las 15:40, Mariano Martinez Peck escribió:

Hi! I am trying to understand how seaside handle double or more, request. I started with the simpler example: WACounter, which has:

renderContentOn: html
  Transcript show: 'renderContentOn'; cr.
  html heading: count.
  html anchor
      callback: [ self increase ];
      with: '++'.
  html space.
  html anchor
      callback: [ self decrease ];
      with: '--'


increase
  Transcript show: 'increase'; cr.
  count := count + 1.
  (Delay forSeconds: 3) wait.


Now, suppose the counter is in 0. I click one time on '++' and wait and I see in the transcipt:

increase
renderContentOn

Ok, perfect. New session, 0 again. Now I click on '++' but before it finish, I click 3 times more (very quickly). I can see this in the transcipt:

increase
increase
increase
increase
renderContentOn

So, as I can see:

1) the callback (self increase in this case) is called for every click.
2) the renderContentOn isn't call until all of the self increase of that session finish.
3) when renderContentOn  is called, the webpage shows the number 1 (which is correct instead of 4).

Now the questions are:

a) how does seaside can do that? every request has its own variables? I think this has to be with continuations but I want to be sure.
b) which of all of the self increase is the one that is finally rendered? the first one?
c) how can I handle the famous double commit? suppose now self increase does something in a relational database (like persisting an order or something like that) and I don't want it to get persisted twice or I don't want an error because of duplicated PK.

Thanks for the help. I just want to understand how this is handle!

best,

Mariano
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2009/8/5 Mariano Martinez Peck <[hidden email]>:

> Hi! I am trying to understand how seaside handle double or more, request. I
> started with the simpler example: WACounter, which has:
>
> renderContentOn: html
>     Transcript show: 'renderContentOn'; cr.
>     html heading: count.
>     html anchor
>         callback: [ self increase ];
>         with: '++'.
>     html space.
>     html anchor
>         callback: [ self decrease ];
>         with: '--'
>
>
> increase
>     Transcript show: 'increase'; cr.
>     count := count + 1.
>     (Delay forSeconds: 3) wait.
>
>
> Now, suppose the counter is in 0. I click one time on '++' and wait and I
> see in the transcipt:
>
> increase
> renderContentOn
>
> Ok, perfect. New session, 0 again. Now I click on '++' but before it finish,
> I click 3 times more (very quickly). I can see this in the transcipt:
>
> increase
> increase
> increase
> increase
> renderContentOn
>
> So, as I can see:
>
> 1) the callback (self increase in this case) is called for every click.
> 2) the renderContentOn isn't call until all of the self increase of that
> session finish.
> 3) when renderContentOn  is called, the webpage shows the number 1 (which is
> correct instead of 4).
>
> Now the questions are:
>
> a) how does seaside can do that? every request has its own variables? I
> think this has to be with continuations but I want to be sure.

I order of you observations:
1) You (your browser) makes three callback requests and discards the
redirect to render for the first two

2) There is a lock that allows only one request per session at a time,
otherwise your components would have to be thread safe
3) state backtracking, before every request the state of the counter
is reverted to 0

> b) which of all of the self increase is the one that is finally rendered?
> the first one?

That should be the last one. The browser should discard processing the
previous requests. Disable backtracking to be sure.

Cheers
Philippe

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2009/8/6 Mariano Martinez Peck <[hidden email]>:

>
>
> On Thu, Aug 6, 2009 at 4:16 AM, Philippe Marschall
> <[hidden email]> wrote:
>>
>> 2009/8/5 Mariano Martinez Peck <[hidden email]>:
>> > Hi! I am trying to understand how seaside handle double or more,
>> > request. I
>> > started with the simpler example: WACounter, which has:
>> >
>> > renderContentOn: html
>> >     Transcript show: 'renderContentOn'; cr.
>> >     html heading: count.
>> >     html anchor
>> >         callback: [ self increase ];
>> >         with: '++'.
>> >     html space.
>> >     html anchor
>> >         callback: [ self decrease ];
>> >         with: '--'
>> >
>> >
>> > increase
>> >     Transcript show: 'increase'; cr.
>> >     count := count + 1.
>> >     (Delay forSeconds: 3) wait.
>> >
>> >
>> > Now, suppose the counter is in 0. I click one time on '++' and wait and
>> > I
>> > see in the transcipt:
>> >
>> > increase
>> > renderContentOn
>> >
>> > Ok, perfect. New session, 0 again. Now I click on '++' but before it
>> > finish,
>> > I click 3 times more (very quickly). I can see this in the transcipt:
>> >
>> > increase
>> > increase
>> > increase
>> > increase
>> > renderContentOn
>> >
>> > So, as I can see:
>> >
>> > 1) the callback (self increase in this case) is called for every click.
>> > 2) the renderContentOn isn't call until all of the self increase of that
>> > session finish.
>> > 3) when renderContentOn  is called, the webpage shows the number 1
>> > (which is
>> > correct instead of 4).
>> >
>> > Now the questions are:
>> >
>> > a) how does seaside can do that? every request has its own variables? I
>> > think this has to be with continuations but I want to be sure.
>>
>> I order of you observations:
>> 1) You (your browser) makes three callback requests and discards the
>> redirect to render for the first two
>
> Ok, but which is the "condition" to be discarded? if the callback request is
> finished but there are others callbacks request then it is discarded?

Seaside doesn't discard anything, the browser has to. Here's a rough
sketch of what happens:
- You initiate a content exchange for the "callbacks page".
- The browser sends a request.
- The Seaside callback machinery kicks in.
- Before Seaside can send a response you initiate three more requests
resulting in three more requests.

Seaside doesn't really have a problem with this, it will process these
requests one after another, meaning "executing" the same "callback
page" several times and send the redirect response to the render page
for each one. However the browser has, he has just one pane where he
can render the resonse. So he'll have to discard all but one of the
responses. The least bad thing is to discard all but the last one.

>>
>> 2) There is a lock that allows only one request per session at a time,
>> otherwise your components would have to be thread safe
>> 3) state backtracking, before every request the state of the counter
>> is reverted to 0
>
> that's because there was the method states ?

Yes

>>
>> > b) which of all of the self increase is the one that is finally
>> > rendered?
>> > the first one?
>>
>> That should be the last one. The browser should discard processing the
>> previous requests. Disable backtracking to be sure.
>
> what do you mean with Disable backtracking ? remove the method states from
> the component?

Yes

Cheers
Philippe
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside