[ 
https://issues.apache.org/jira/browse/TAP5-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935612#action_12935612
 ] 

Thiago H. de Paula Figueiredo commented on TAP5-1355:
-----------------------------------------------------

Hi, Josh!

Instead of reverting the TAP5-834, which would cause other problems, what about 
putting that two statements in a synchronized block?

syncronized (session) {
                session.setAttribute(attributeName, null); 
                session.setAttribute(attributeName, attributeValue);
}

> Threading issue with SessionStateObjects
> ----------------------------------------
>
>                 Key: TAP5-1355
>                 URL: https://issues.apache.org/jira/browse/TAP5-1355
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: tapestry-core
>    Affects Versions: 5.2.4
>            Reporter: Moritz Gmelin
>         Attachments: Screenshot.png.jpg, taptest.tgz
>
>
> When a page request consists of multiple HTTP request (e.g. page and some 
> dynamically generated images) and all those requests access a 
> SessionStateObject, it happens that a new session (with an empty SSO) is 
> created for some of the request threads.
> I was able to create a very simple example to recreate that problem:
>       -A simple page that displays 20 dynamically generated images in a loop.
>       -In the page, a SSO, holding a number value is initialized to a random 
> number.
>       -Each of the dynamic images read that number and draws it.
>       -Make sure that a HTTP-Request is made for every image on the page (by 
> adding some random number to the event link)
> The effect that you'll see after some reloads of the page (maybe you need to 
> reload 30 times) is that some images will draw 0 as SSO value instead of the 
> number set in the page @BeginRender method. Those fields will be marked in 
> red in the demo so you can quickly see them. 
> I definitely beleive that tapestry should take care of this. It is a use case 
> for SSOs that is probably too common to ignore. 
> Why can't this be automatically integrated into the ApplicationStateManager?
>  
> The demo has been deployed here
> http://www.avetana.de/taptest/

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to