Ok, just to follow up. I tracked it down and commented on the defects involved. > https://issues.apache.org/jira/browse/TAP5-1355 https://issues.apache.org/jira/browse/TAP5-834
Tapestry has two lines of code which set a session attribute to null and back in order to force updates to clustered servers... not my area of expertise. If you're not in a clustered environment, or possibly using an app server other than Tomcat/Jetty, then your SSO could extend org.apache.tapestry5.OptimizedSessionPersistedObject and always return false in isSessionPersistedObjectDirty. This would circumvent the code that temporarily sets the session attribute holding your SSO to null. If you aren't changing the values inside the object then it should be a safe approach. I'll try to work out a real solution for 5.3... the fix might be a little risky for a 5.2.4 release. Josh On Wed, Nov 24, 2010 at 12:16 AM, Moritz Gmelin <moritz.gme...@gmx.de> wrote: > Thanks > > https://issues.apache.org/jira/browse/TAP5-1355 > > Moritz > > Am 24.11.2010 um 00:29 schrieb Josh Canfield: > >> Can you put the test case into jira? I'll try to look at it over the >> holiday/weekend. >> On 23 Nov 2010 13:16, "Moritz Gmelin" <moritz.gme...@gmx.de> wrote: >>> Hi, >>> >>> 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 (my >> adding some random number to the event link) >>> >>> The effect that you'll see after some reloads of the page is that some >> images will draw 0 as SSO value instead of the number set in the page >> @BeginRender method. >>> >>> 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? >>> >>> Thanks >>> >>> Moritz >>> >>> >>> >>> >>> Am 23.11.2010 um 16:06 schrieb Thiago H. de Paula Figueiredo: >>> >>>> On Tue, 23 Nov 2010 12:30:42 -0200, Moritz Gmelin <moritz.gme...@gmx.de> >> wrote: >>>> >>>>> Hi, >>>> >>>> Hi! >>>> >>>>> Is this a design problem with my application that multple threads can >> access the sessionstateobject at the same time and thus break its uniqueness >> or is it tapestrys fault that it does not prevent it from breaking? >>>> >>>> It's not Tapestry's nor the servlet container to handle concurrency on >> session objects. I suggest you to create a service that synchronizes access >> to your SSO and use it instead of using @SessionState and >> ApplicationStateManger directly. Another option is to decorate or override >> ApplicationStateManager to add thread syncronization to them. >>>> >>>> -- >>>> Thiago H. de Paula Figueiredo >>>> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, >> and instructor >>>> Owner, Ars Machina Tecnologia da Informação Ltda. >>>> http://www.arsmachina.com.br >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>>> For additional commands, e-mail: users-h...@tapestry.apache.org >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: users-h...@tapestry.apache.org >>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
