I have run into a rather tricky session problem (or so I think :) )...

To explain my setting I have a webapplication (running in WebLogic) having a rather large persisted object graph. So one of my wishes are to do lazy collections etc.

We have implemented the SessionFilter approach describe in the "Hibernate in Action" book, and 90% of the time it works ok.

The problem occurs when impatient users do clicking around in the application (always these users seems to cause problems :-) ). The problem is handling two requests at once which of course results in two concurrent threads.

So getting to my question - is there a standard pattern for handling concurrent requests from the same user in a webapplication?

I've browsed the forum and docs - but there doesn't seem to be any good solution. It is kind of a delicate problem. I suppose I could synchronize and block subsequent threads (from the same user) - but then again doing so in a web application is not really a thing I'd like to do. Another alternate I've considered was moving to one hibernate session per request. But this really doesn't solve the problem because the objects are the same and concurrent request would then try to attach the same object graph to different HibernateSessions.

If somebody has a solution I'd like to hear?

just add "serialization" of httprequest in another filter

Yes, that is in effect what I have done by using synchronization in the hibernate filter (synchronizing on the users session). I just wanted to avoid this if at all possible - cause the really impatient use just starts to queue request stealing our application server threads as he does so. Worst case a DOS scenarie...

You could return an error page if two requests come in on a single httpsession (using a filter). Not nice to them, but it sounds like they are being bad monkeys.
I don't see the problem with having a hibernatesession per request. Seems like a simple session-per-transaction setup.

Yes, I think I'll do something along the lines of ensuresing the queue of requests doesn't grow into an effective dos attack. So that the user gets the error page when reaching a threshold of "parked" threads...

Thank you the answers - confirmed my own thinking and that is of course always nice :)