tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Denis Stepanov (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TAP5-2049) Tapestry should provide locking semantics for attributes stored in the session, to prevent multiple simultaneous requests (due to Ajax) from conflicting
Date Sat, 12 Jan 2013 19:38:14 GMT

    [ 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

Mime
View raw message