Hi,

I added the logging as you suggested. This is part of the logging for a 
_SINGLE_ page request. CurrentSessionASO is our SSO.

10-10-14 21:51:12.049 [DEBUG]   
de.example.aso.CurrentSessionASO.valueBound(CurrentSessionASO.java:1587)        
session 1vsqjhkzdsj37 asoHash 1363402032
10-10-14 21:51:12.066 [DEBUG]   
de.example.aso.CurrentSessionASO.valueUnbound(CurrentSessionASO.java:1595)      
session 1vsqjhkzdsj37 asoHash 1363402032
10-10-14 21:51:12.066 [DEBUG]   
de.example.aso.CurrentSessionASO.valueBound(CurrentSessionASO.java:1587)        
session 1vsqjhkzdsj37 asoHash 1363402032
10-10-14 21:51:12.069 [DEBUG]   
de.example.aso.CurrentSessionASO.valueUnbound(CurrentSessionASO.java:1595)      
session 1vsqjhkzdsj37 asoHash 1363402032
10-10-14 21:51:12.070 [DEBUG]   
de.example.aso.CurrentSessionASO.valueBound(CurrentSessionASO.java:1587)        
session 1vsqjhkzdsj37 asoHash 1363402032
10-10-14 21:51:12.073 [DEBUG]   
de.example.aso.CurrentSessionASO.valueUnbound(CurrentSessionASO.java:1595)      
session 1vsqjhkzdsj37 asoHash 1363402032
10-10-14 21:51:12.074 [DEBUG]   
de.example.aso.CurrentSessionASO.valueBound(CurrentSessionASO.java:1587)        
session 1vsqjhkzdsj37 asoHash 950050904
10-10-14 21:51:12.074 [INFO]    
de.example.services.AppModule$3.create(AppModule.java:220)      New 
CurrentSessionASO object created CurrentSessionASO{user:0, account:0, 
patient:0, project:, hash:950050904} for session 1vsqjhkzdsj37
10-10-14 21:51:12.077 [DEBUG]   
de.example.aso.CurrentSessionASO.valueUnbound(CurrentSessionASO.java:1595)      
session 1vsqjhkzdsj37 asoHash 950050904
10-10-14 21:51:12.079 [DEBUG]   
de.example.aso.CurrentSessionASO.valueBound(CurrentSessionASO.java:1587)        
session 1vsqjhkzdsj37 asoHash 1363402032
10-10-14 21:51:12.080 [DEBUG]   
de.example.aso.CurrentSessionASO.valueUnbound(CurrentSessionASO.java:1595)      
session 1vsqjhkzdsj37 asoHash 1363402032
10-10-14 21:51:12.080 [DEBUG]   
de.example.aso.CurrentSessionASO.valueBound(CurrentSessionASO.java:1587)        
session 1vsqjhkzdsj37 asoHash 950050904
10-10-14 21:51:12.084 [DEBUG]   
de.example.aso.CurrentSessionASO.valueUnbound(CurrentSessionASO.java:1595)      
session 1vsqjhkzdsj37 asoHash 950050904

You can see that the CurrentSessionASO is bound and unbound many times for a 
signel page request. Sometimes (as you can see in the log here), a new 
CurrentSessionASO object is created for the same session. This is done in my 
ApplicationStateManagerContribution in AppModule. Most often times, there is no 
new SSO created (correct behaviour).

I'm starting the applcation here locally in a jetty environment. One weird 
observation is also that about half of the startups of the application the 
situation is totally different. Then, our SSO is only bound and unbound once 
per page request, as I would expect. But the other times the situation as above 
happens, that for every page request binding and unbinding happens about 20 
times. and sometimes a new SSO is created inbetween.

Next thing to notice is that this all happens after the cleanup method of the 
page is called. 

Thanks

Moritz



Am 14.10.2010 um 19:13 schrieb Howard Lewis Ship:

> Tapestry manages persistent state in the HttpSession.  As of 5.2, it
> doesn't do anything special to handle cases of multiple requests
> (perhaps due to Ajax) attempting to modify the same SSO in multiple
> threads.
> 
> This aligns with Brian Goetz's observation that all stateful web
> applications are inherently broken:
> 
> http://www.ibm.com/developerworks/library/j-jtp09238.html
> 
> I'm not aware of any concerns.  You may want to have your SSO
> implement the HttpSessionBindingListener interface, and log the
> details of when it is bound (saved to the HttpSession). That might
> illuminate what's going on.
> 
> It may be a bug in your servlet container, it may be a race condition
> between threads, or it may just be a coding problem in your code.  I
> hate to say it, but the last option is the most likely (given the
> total lack of information you've provided).
> 
> On Thu, Oct 14, 2010 at 3:01 AM, Moritz Gmelin <moritz.gme...@gmx.de> wrote:
>> Hi,
>> 
>> since upgradeing to Tapestry 5.2 (5.2.0 and 5.2.1) we sometimes obseve that 
>> the contents of our SessionStateObject gets lost.
>> The Session-ID between 2 requests is identical, but the Hashcode of the 
>> @SessionState object changes and thus the contents are lost.
>> If everything works correctly, the getHashCode() of the SessionState object 
>> does not change between requests. But in the case where our SessionState 
>> objects get lost beweeen requests, obviousely a new SessionState object gets 
>> created.
>> This happens only in very rare cases but if it does, our users get chucked 
>> out of their pages.
>> This has not happened with t5.1.0.5 as far as we can see.
>> 
>> Has anyone else seen this problem yet? Any hints about a possible solution?
>> 
>> Thanks
>> 
>> Moritz
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>> 
>> 
> 
> 
> 
> -- 
> Howard M. Lewis Ship
> 
> Creator of Apache Tapestry
> 
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
> 
> (971) 678-5210
> http://howardlewisship.com
> 
> ---------------------------------------------------------------------
> 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

Reply via email to