THANKS AND… GREAT WORK!!

THANKS AND… GREAT WORK!!

Good post, though I seem to be reading it pretty late .

I have a somewhat similar problem and thought you might interested in giving some input. Though Hibernate is not new to me, but the current project that I am handling is about 6 months old. And now we have the requirement of splitting the application into 2 (or more) parts. Since that was not an original requirement, the simple design of this application did not take into account this possibility.

The scenario is simple enough, with Hibernate configuration files and POJO files forming a layer between the service layer and the MySQL database. In the front end we have Struts based action classes. The service layer, creates a Hibernate session and uses it for the purpose and discards it on use. Now if we split the application, into 2 parts, there is bound to be sync problem between the 2 hibernate sessions each part creates.

So my problem is “how do we maintain the two hibernate sessions in sync”? Any alternate solution to this existing system can also be applied.

Thanks for you patience !!
Chet

When Hibernate loads an Object with load() (or with get() for that matter), the Object is always persistent – i.e., associated with the session. (Contrast this with merge(), where the object passed in remains transient or detached.) Therefore, the Object you pass in to load needs to return as a persistent Object. Those are the semantics of the method. Hibernate obviously can’t have two separate persistent Java objects for one database record – if it did, how would it know which one’s state to save?

If there were a get() method to load state into an existing Object, it would do precisely the same thing, but having such a method wouldn’t be logical – since get() can’t load null state into the existing Object, and returning null is pretty much get()’s only purpose.

The difference with the Object-returning method is that, if there is an existing persistent Object already associated with the session, it just returns that Object – and therefore doesn’t have the duplicate reference problem. (Hibernate refers to these internally as reload and load events respectively.)

It was mentioned above that Hibernate is too complicated. Perhaps the real problem is that it looks so much easier than it is. A lot of people get confused about things like the one I just mentioned because they think of Hibernate as a simple wrapper around a database, whereas it’s actually a fundamental shift in thinking about persistence. Anyway, good article – if only for the discussion it provoked.