-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 3 posts ] 
Author Message
 Post subject: Best practice question: Long-running Sessions vs. Exceptions
PostPosted: Thu Jul 21, 2011 5:07 am 
Senior
Senior

Joined: Fri May 08, 2009 12:27 pm
Posts: 168
I'm somewhat at a loss about how to actually use a long-running Session in practice.

The problem is with Exceptions: I have no idea how to deal with them without compromising the application's modularity.
The normal approach would be: rollback, close Session, create a new Session.
Trouble is: Any module in the application might have now-detached objects lying around. They need to be reattached, usually through a merge() in a newly opened Session.

But how do I find out which POJOs are actually entities and need to get merged?

Approach 1: For each object that needs to be merged, have a piece of code that does that.
Approach 2: Subclass Session and keep a list of all managed entities.
Approach 3: Use an Interceptor and keep a list of all managed entities.
Approach 4: Cast Session to SessionImpl and dig through the data structures until you find the first-level object cache. That's the entities that need to be reattached.

None of the above approaches are satisfactory.
#1 is inherently unmodular. It's also error-prone since programmers tend to neglect/overlook the exceptional case (I know I do, particularly under deadline pressure).
#2 is hard to get right. For example, delete() makes an entity detached, but after rollback, it should be merged anyway because the record has reappeared in the database; the next complication is cascading persists and deletes. Also, duplicating work that Hibernate already does for its internal object cache is disgusting.
#3 has essentially the same problems as #2.
#4 avoids duplication of work and would probably be easier to get right, but it's prone to breakage as Hibernate evolves.

Does this mean that long-running sessions are a hopeless case?
Or did I overlook an approach?


Top
 Profile  
 
 Post subject: Re: Best practice question: Long-running Sessions vs. Exceptions
PostPosted: Mon Aug 08, 2011 7:21 am 
Senior
Senior

Joined: Fri May 08, 2009 12:27 pm
Posts: 168
*bump*

Sorry, but I need to know...


Top
 Profile  
 
 Post subject: Re: Best practice question: Long-running Sessions vs. Exceptions
PostPosted: Mon Sep 05, 2011 11:17 am 
Senior
Senior

Joined: Fri May 08, 2009 12:27 pm
Posts: 168
Okay, seeing that I haven't gotten an answer in almost a month now, I guess that there is either no answer, or nobody knowledgeable is willing to answer on that (which is almost as bad).

I do hope somebody does have a good answer.
This is my last attempt at getting a useful answer out of this. I have already spent two years of my professional life, constantly under the impression that I'm fighting an uphill battle against the tool.
I feel myself forced to the conclusion that Hibernate's design around sessions is fundamentally broken by design. Please prove me wrong.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 3 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.