The key is acquiring a RL in ClusteredSessionValve:
| // let the servlet invocation go through
| Lock lock = manager.getReadLock(requestedSessionId);
| lock.lock();
| try
| {
| if (isEvent)
| {
| getNext().event(request, response, event);
| }
| else
| {
| getNext().invoke(request, response);
| }
| }
| finally
| {
| lock.unlock();
| }
|
The stuff inside that try/finally block encapsulates the application code's
interaction with the session. The lock returned by manager.getReadlLock(...) is
the RL from a java.util.concurrent.lock.ReadWriteLock. When any replication
activity happens, it happens outside the above block and the corresponding WL
is acquired.
Result is, application code will not be manipulating the session when the WL is
held. Application code doesn't need access to the RL as it will never be
conflicting with the replication code.
Unspoken and unproven assumption here: there is a sufficient benefit to having
*guaranteed* lockout of application activity. One benefit is it removes the
need for the application to synchronize.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240432#4240432
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240432
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user
