Re: Synchronize wrapper for session obj attrib get/set
Leon, Chuck: Thankyou very much for (1) pointing out that tomcat has internal session obj accesses, so go with something that accomplishes a global fix and (2) just as important: what the current patches are for 5.0.19+. Leon, I went with your pre-compiled StandardSession.class and replaced the original one in the catalina.jar and am up and running. Thanks again, gentlemen. Maurice Yarrow Leon Rosenberg wrote: Possibly the easiest thing to do is edit the StandardSession.java file and change the type of the attributes field to HashTable rather than HashMap, then rebuild the associated jar. The places that already synchronize on attributes can be left alone, since redundant synchs are allowed and have minimal performance impact. - Chuck Or, you take one of existing patches, see also: http://www.niallp.pwp.blueyonder.co.uk/TomcatBug36541.html or, you just get the last StandartSession version out of CVS ( sorry SVN since this weekend) , and compile it. regards Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Synchronize wrapper for session obj attrib get/set
Hello Tomcat people
For those not wishing to migrate at this time to 5.5.12
(in our case, from 5.0.28 and jdk 1.4) would the following
be sufficient for preventing deadlock access of the session
objects ?
In a given servlet, say, ServletA, for example, might have:
HttpSession session = getSessionCheckValid( request );
synchronized( session ) {
session.setAttribute( particularAttribName,
particularAttribVal );
}
The question arises, if this session obj is being used from
a variety of such servlets, does the above code in ServletA
prevent simultaneous access to the set method of the same obj
in a similar synchronized block in some other servlet, say,
in ServletB ?
If, on the other hand, one chooses to write a class extending
the HttpSession interface, and then (2) wrap the get/set and other
applicable methods with synchonized methods, then what is the
minimum amount of threading machinery that must to be provided
(i.e., Runnable, run(), etc) to accomplish this wrapping ?
For that matter, has someone done this who would be willing
to share such code ?
Maurice Yarrow
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Synchronize wrapper for session obj attrib get/set
From: Maurice Yarrow [mailto:[EMAIL PROTECTED] Subject: Synchronize wrapper for session obj attrib get/set For those not wishing to migrate at this time to 5.5.12 (in our case, from 5.0.28 and jdk 1.4) would the following be sufficient for preventing deadlock access of the session objects ? No. As Wade C and others have pointed out, there are numerous unsynchronized get/set invocations within Tomcat itself, and these have the potential for unexpected behavior. (Note that the problem is not deadlock, but infinite loops and erroneous results.) Possibly the easiest thing to do is edit the StandardSession.java file and change the type of the attributes field to HashTable rather than HashMap, then rebuild the associated jar. The places that already synchronize on attributes can be left alone, since redundant synchs are allowed and have minimal performance impact. - 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Synchronize wrapper for session obj attrib get/set
Possibly the easiest thing to do is edit the StandardSession.java file and change the type of the attributes field to HashTable rather than HashMap, then rebuild the associated jar. The places that already synchronize on attributes can be left alone, since redundant synchs are allowed and have minimal performance impact. - Chuck Or, you take one of existing patches, see also: http://www.niallp.pwp.blueyonder.co.uk/TomcatBug36541.html or, you just get the last StandartSession version out of CVS ( sorry SVN since this weekend) , and compile it. regards Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
