|
History
| Log In
|
|
|
|
I don't have much experience with synchonization but this one looks straight foward. I used synchronized methods rather than synchonized blocks in the methods because I don't see too much benefit in messing with fine-grained locking and the performance difference seems minimal. I don't see a way to unit test this
There's a good (heated) discussion of the issue here: It seems like some containers may already synchronize some (or all) methods of the session. I have already begun work on the unit test for this, pending some Groovy/threading issues.
Thanks for the patch, I will check it out once we have a unit test that fails Happy happy joy joy, that Tomcat bugzilla discussion is crazy.
Thing is, they say that Servlets spec 2.5 will clarify this issue. I cannot find a copy of the Servlet 2.5 spec PDF (as opposed to the javadocs) and so I cannot see what, if anything, they have indeed changed. The only way to be My take-away from the heated discussion on the Tomcat list is that the overhead of synchonization (at least as measured via microbenchmarks) is negligible, so why not be safe.
Yes me too - but even if they weren't we need to be safe. We don't want to end up saying "Grails won't run reliably on container X or Y"
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Closed
Blocker
Automatically synchronize access to session
#. Simultaneous requests on other threads are always possible if not inevitable when you factor in Ajax requests, image serving, templated CSS, rapid user clicks (i.e. clicking on a link in result page before the GSP has fully executed) etc
#. Session affinity across servers surely relies on synchronisation to ensure the state of the local session is coherent during exchanges of data between servers