[
https://issues.apache.org/jira/browse/TAP5-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13552018#comment-13552018
]
Denis Stepanov commented on TAP5-2049:
--------------------------------------
Obviously, exclusive session access is a bad idea:
- We have many concurrent ajax request, this change means major performance
issue for us!
- This will not work in a clustered environment, the clustered session class
shouldn't inherit the locks functionality.
- Tapestry should not do this by default, any kind of synchronization between
the requests is bad idea and should be avoided at any cost.
Please do not force every Tapestry user to have this, if you want it in your
apps just advice the session factory and return exclusive session delegate.
> Tapestry should provide locking semantics for attributes stored in the
> session, to prevent multiple simultaneous requests (due to Ajax) from
> conflicting
> --------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: TAP5-2049
> URL: https://issues.apache.org/jira/browse/TAP5-2049
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.4
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
> Labels: session, thread-safety
> Fix For: 5.4
>
>
> Currently, multiple threads may be processing requests, due to Ajax. If they
> all access state stored in the HttpSession, the rsult can be invalid.
> Tapestry should maintain a lock object inside the session, and automatically
> acquire a read lock the first time a request thread reads values from the
> session, and upgrade to a write lock when writing values to the session.
> The lock can be released at the end of the request.
> A reentrant read/write lock may be insufficient, as values inside the session
> are mutable; it is possible that the lock should be exclusive.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
