[TAP5-2049] Tapestry should provide locking semantics for attributes stored in the session, to prevent multiple simultaneous requests (due to Ajax) from conflicting

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 5.4
• Fix Version/s: 5.4
• Component/s: tapestry-core
• Labels: session thread-safety
• Assignee: Howard Lewis Ship
• Reporter: Howard Lewis Ship
• Created: 09/Jan/13 23:12
• Updated: 27/Jun/14 16:14
• Resolved: 11/Jan/13 17:27

Description

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.

Issue Links

• incorporates: TAP5-2037 ValidationTracker/Flash persistence race condition with AJAX
• is related to: TAP5-2357 Release global session write lock if only immutable attributes are read