Hi,

Just finished Hibernate in Action. Great book - thanks!

One minor nit. On page 328 the book recommends avoiding the problem of form double-submission by serializing the HTTPSession object.

Actually, this doesn't work in all containers. Since HTTPSession is an interface facade not an object this might be a different object for different requests. Serialize on an object in the session instead.

I've explicitly found this to be required in Tomcat 4.1.

a reference:
http://www.mail-archive.com/tomcat-user ... 08029.html

WILL

I also think that this should be corrected in the book and put in the errata.

The assumption made by the authors that there is a single HttpSession instance for one sessionid has no support in the J2EE Servlet Specification. The container is free to use several concurrent HttpSession instances for one "user session", even in the same webapp and JVM. Thus, there is no single HttpSession instance to use for synchronization.
The rules for session attributes are stricter, so typically you would create one of these to sync on instead, just as wglass mentions.
BTW, BEA Weblogic also exhibits this "multiple HttpSession instances" behaviour.

Even though this book is not about learning webapp programming I think it is unfortunate that ill advice like this has not been edited out, as the "sync on HttpSession" pattern introduces extremely subtle and hard-to-find concurrency bugs.

I apologize for not writing a perfect book. I will add it to the errata if I've time.

Ha! Christian, this is one of the best tech books I've read this past year. I gave a copy as a Christmas present to each member of my team.

Thanks for addressing this extremely minor point.

Hello,

wglass & mikewse - I just posted a very related question here:
http://forum.hibernate.org/viewtopic.php?t=940560

Since Hibernate Session is not thread-safe, and a user can make several requests to a webapp in parallel, how do people typically handle these parallel requests? How do you do it? Obviously, you don't synchronize on HttpSession :) Do you synchronize on the Hibernate Session? In the servlet filter or?

Thanks,
Otis

Use a homemade mutex object. In your code, synchronize as follows:



then write a utility class with these methods



Note that this could be criticized on the grounds of containing the antipattern "double-checked locking" except that the mutex is an immutable object.

[A late followup - where did those reply notifications go...? ;-)]


Do you mean to use the "testing purposes" branch when there is no request or no session? (The comment and code are sort of contradictory.)

If it is for the case of no request all is fine as this branch would never trigger during normal webapp runtime. But if you actually mean to test for no session, then you have a Denial of Service vulnerability in this code as this branch would trigger for all requests from new clients that haven't yet had a session created for them.

The Denial of Service problem is that those clients will all be synchronized on the same object (the shared constant object Boolean.TRUE) and only one of them can execute at a time. If one of the clients for some reason stops communicating with your server (there are bugs in IE that can cause this) while holding the lock, all other new clients will have to wait for your server to timeout the hanging connection. Depending on your server, this timeout may be set to anything between 30 secs and infinite.

Also, be aware that the call
HttpSession session = getRequest().getSession();
will create the session if it doesn't exist. If this is what you want all is fine, but if you have code paths in your server that do not rely on the session, and you don't want to create unnecessary sessions, consider using getSession(false) instead.

BTW: I like the dual-check thingie. It's nice to wait with acquiring the container-wide lock until it's absolutely necessary!

Hi,

You can just ignore the null check for getRequest(). The code excerpt was from a recent project that is sometimes run by test code outside of a servlet. In such cases there is no request object. Since the test code is running in single thread mode there is also no need to get a true session mutex.

WILL