I'm serializing the requests to prevent hibernate from trying to
associate an entity with more than one session. Most of the research
that led to this approach was done in the hibernate2/tapestry3 days, so
some of it may be outdated. I believe the rest of my state is
sufficiently thread-safe that I wouldn't need this if it weren't for
hibernate.
Generally, it's not a performance problem, but my production code is
only making light use of ajax. That's going to change soon. Some older
code does use pre-ajax iframe swapping though, and that performs well.
The only problem I've seen is if a user tries one of a few long
operations and then changes their mind and clicks on something else. My
filter still waits for the long operation to complete or timeout
(configured to 20 seconds) before beginning the user's new request.
I got hooked on spring before tap4, so I never gained mastery over
hivemind. I can't really tell you how to craft hivemind-based DAOs. If
you're using a DAO setup, you probably need to explicitly reattach in
the DAO methods rather than using tapernate to do it automatically.
Personally, I'm moving towards tapernate-style re-enlistment and away
from a kludgy aspect.
-Steve
Michael Sims wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
