> From: Mark Thomas [mailto:ma...@apache.org] > Subject: Re: Tomcat Clustering Support
> Thread A is in the middle of processing a request. It is evaluating some > EL which requires access to the view map which in turn causes the > ViewMap to update the session. > com.sun.faces.application.view.ViewScopeManager.processEvent locks the > ViewMap object. It then tries to update the session. To do this it > requires the session lock. Thread A is waiting for this lock. Assuming the ViewMap is used by multiple sessions, this locking order goes against the usual protocol of more local before more global. Might be possible to file a bug report with Mojarra, but given that the code appears to be in a com.sun class, that might not get anywhere. > Thread B is at the end of a request. The session has been updated and it > is attempting to write the updated session attributes to the cluster. > The session lock has been obtained. The individual attributes are being > written. The code has reached the ViewMap object. In order to write this > object, the ViewMap object must be locked. Thread B is waiting for this > lock. This is the generally the more desirable order. > Has anyone on the users list come across this problem before? If so, how > have you solved it? Suggestions for alternative solutions also welcome. Can the thread doing the session synchronization lock the session, get a shallow copy of the attributes, unlock the session, then process the attributes? Not sure if that would maintain sufficient coherency. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
smime.p7s
Description: S/MIME cryptographic signature
