I know this isn't strictly Tapestry related, but since there has been a lot of discussion here over the years related to integrating Hibernate with Tapestry, I was hoping I could draw on the community knowledge about this topic and get a little advice. My apologies if this has been discussed before, I did extensive searching before posting but still might have missed something.
My specific dilemma at the moment is how to implement session-per-request with detached objects in a thread-safe manner. Chapter 8 of the _Hibernate in Action_ book discusses the issues of detached objects and thread safety. It gives the example of a user submitting a form twice, and I can think of several other scenarios which would cause two or more threads to access the HttpSession simultaneously. The book suggests a few solutions to this problem: rejecting additional requests if one is currently processing, serializing all requests from the same user by synchronizing on the HttpSession in a servlet filter, and finally maintaining a map of session information to separate windows in a multi-window application. None of these solutions seem to be workable in my situation. We are making extensive use of assets for all of our images and CSS files, so there really is no static content in our application; every request is going to be serviced by the servlet. The first two solutions aren't practical as even loading my application's login page will open at least 4 concurrent requests (two CSS files, several images, the HTML document, etc.) and if these requests are serialized I am of the opinion that this will noticeably impact perceived performance of the application and will impact scalability in the long run. The final solution (mapping between windows) doesn't solve the issue of users opening multiple tabs or windows as each window will have the same name/identifier. So, I'm struggling to come up with a solution to this that doesn't require me to abandon detached objects. I have an idea for a solution, but it seems cumbersome and I was hoping to get some suggestions or feedback on this. My idea is to explicitly synchronize only the sections of the code in my request action handlers that have to work with the potentially shared detached objects. My plan is to synchronize either on a mutex object, or one of the detached objects, and within the synchronized block update() the detached object, perform my model manipulations, commit the transaction, close the session, then end the lock. It would still be possible for more than one thread to share a given detached object, but this would prevent my code from attempting to attach the object(s) to more than one session simultaneously. (As an aside, I looked at the Tapernate code, since it includes persistence strategies that use Hibernate detached objects. However, unless I'm missing something, it doesn't seem to be taking thread safety of detached objects into account at all, which I find curious.) Can someone with a little more experience with this sort of thing give me some advice on this? Does my approach above sound workable, or is there something better that some of you are already doing? Should I just forget about detached objects and squeeze/unsqueeze my entities down to identifers and retrieve them anew on each request? Any help or advice would be greatly appreciated... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
