DWR

Per Mike on the mailing list:

Hi Lance and others,

I think we discussed the solution for this quite a long time ago on the mailing list, when talking about how to make engine.js static for 3.0 (previously the script session id was merged into a dynamically generated engine.js).

IIRC it goes something like this:

*
When the page is loaded there will be no script session id, neither before or after the inclusion of engine.js.
*
The first remote call from the DWR layer will be done in |ordered| mode (an existing feature in DWR) to ensure that no other call takes place until it returns. As it will send a null scriptSessionId to the server, it will create a new id and return back to the client, so the id can be set in the DWR client layer for the remainder of the page lifetime.
*
The first remote call (for this page's lifetime) could be the user code's first remote call, the first Reverse Ajax poll, or the System.pageLoaded call.
*
After the script session id has been set the DWR client layer can go back to normal/non-ordered mode.

If things haven't changed since we discussed this, I think this is the correct way to implement/correct this feature.

Best regards
Mike

A recent discussion with Joe in the "File upload progress" thread on the mailing list gives that we can probably switch to client-generated scriptSessionIds. That would take away this problem altogether. Hopefully I can implement that part after the summer.

Thanks for the update Mike.

Client-generated scriptSessionIds will likely conflict with DWR-320. We probably need to decide which way we want to go.

I believe similar problem arises when engine.js has been included twice on the same page, and there are two reverse ajax services used on the same page.

Then both __System.pageLoaded.dwr requests get different scriptSessionId in the response, and calls to the exposed service methods uses the last one of them (or they use both different ones, which is the error situation! Happens at least with IE8 on the second request to the same page). Then ReverseAjax.dwr request starts to use only the last got scriptSessionId, and therefore the first service does not start, only the last service starts responding to polls.

I guess that ideal would be that both engine.js includes, i.e. calls __System.pageLoaded.dwr would get the same scriptSessionId as response. Or is it just a documention problem...

David wrote:
> Client-generated scriptSessionIds will likely conflict with DWR-320

I think we can probably handle this without much problems. If the id has already been set server-side, then we just skip running the client-side algorithm. But you are very right that we should coordinate this effort with DWR-320.

Switching to client-side generation of scriptSessionId still needs to open up for delivery of a server-side scriptSessionId from DWR-320 JSP tags.

This issue has now been resolved and the script session id is now obtained in a different way that avoids duplicates. See description of changes in DWR-26.