Hi Steve, Steve Shucker wrote: > I'm not sure if this will completely solve your problem, but I wrote > my own WebRequestServicerFilter that only applies the > session/transaction wrapping on non-asset requests.
Interesting! Thanks for that. There will still be some non-asset requests in my application that won't hit the Hibernate stuff, but this will take care of a good bit of unnecessary locking if I ultimately go that route. > I actually wrote a generic wrapper and then subclassed it into a > WebRequestSericerFilter for tapestry and a ServletFilter for the rare > occasions when I need a non-tapestry request wrapped. The reason I > have both versions is specifically so I don't blindly apply the > wrapping to asset requests. The filterRequest method in the > superclass serializes the requests. So, just curious, are you serializing your requests for the same reason as I (i.e. Hibernate detached objects)? Or are you doing it just in general so that you can place non-thread safe objects in your HttpSession? Have you noticed any performance impact from the serialization? > If you're really worried about high throughput and contention issues, > using DAOs for narrower transactions may be your best bet. If I was > going down that road, I'd be looking at using spring to broker my DAOs > and seeing if I could subclass their base DAO class to build in the > mutex support. I'm using Hivemind as my app-wide DI container, and it is injecting my DAOs into the classes that need them. The problem with locking within the DAO is that I need to lock starting from the point that I reattach (via Session#update(), merge(), or lock()), to the point that I detach (via evict() or closing the Session), and this will span many calls to various DAOs. Thanks for taking the time to respond... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
