A newbie question.

Any way to get subsequent calls to Hibernate to return the SAME object, not its equals()?

I am developing a Swing app. I want to use Hibernate to fetch/persist my (non-visual) Java Beans, such as Person for example; instead, it creates (in memory) multiple versions of identical Java Beans (multiple Persons with the same id). This is problematic in Swing context, since how do I implement MVC with that? How do I tie together different views of the same model, when one view is updating one instance of the model, and the other view, the other, identical, instance?

Of course I can implement my own, "3rd level" cache of persistent objects to avoid duplications; but that defeats the purpose of an ORM, no? Then I'd probably forfeit on all Hibernate associations/cascades, since I have to implement my own object model independent of hibernate anyway. Or am I missing an important paradigm shift?

My sessions are very short; I seek to remember some state between sessions.

Within the same session Hibernate will always return the same object. So i hope u use at least a one-session-per-request approach (with Struts2 i implemented an Interceptor that opens and closes the session for me, i think SpringMVC has something similar!?)
To handle Objects accross multiple requests implement a conversation.

regards,
Stephan

Thanks. This definitely helps.

As does this: http://www.hibernate.org/333.html ("Best Practices for Thick-Client Applications (i.e., non-web apps.)",

So it looks like Hibernate is not used in 2-tier thick client applications very often, and such usage is tricky. Has anyone had any luck with ANY ORM frameworks with Swing, where you want to implement application-wide object identity? What works best?

I can maintain one humongous session at least for read-only; but then, what happens if I get a Hibernate exception and the session needs to be closed? I want my application to recover!

Why would you want do create your own "3rd level cache"? A second level cache could be sufficient for your needs. What are the problems you face right now?

To be of any help, 2nd level cache must mean long conversations, right? I am a little worried about implementing a long conversation. For instance: what happens if a Hibernate exception is thrown and a session needs to be closed, can I just reattach my object structure to another session without causing another exception?

No, actually a second level cache is a cache, which can span over multiple sessions, whenever you try to load an entity, which is already in this cache, you get the same object.

Be careful that you use the cache the right way, I posted the link to the reference guide above.

But still, what are the problems you face, making it absolutely necessary to get the same objects?

Thanks for the reference; sounds like the way to go. I'll check it.

Why do I need unique objects? Well, if you've had a chance to program Swing... it's a flavor of Model/View/Controller... single Model, different Views of it... every time a model object (a Person for example) changes, it fires events to which Views subscribe.. each View knows how to update itself. However, if there are two copies of the same Person, then one of them changes (forcing its View to be changed), the other one does not, resulting in stale data being shown. Kind of flies in the face of the way Swing is usually done.

On an unrelated subject - I am a total Hibernate newbie and won't be able to earn credits any time soon; would be nice if credits could be bought, no? Just sayin', in case someone is listening to this.

I also programmed a big Swing-Application using hibernate. And you are right, we also had problems implementing an observer-pattern for our different views on the 'same' object. We solved this problem using JMS: Each client send a message to a topic every time an observed object changed. Also, every client was listening to that topic, so each time a changed message was received, every view could refresh itself. That way views were also refreshed on other clients in our multi-user application.

JMS, that's an interesting solution, I have not thought of that; what in your opinion are the pros and cons of 2-tier vs. 3-tier, in this situation? What influenced your decision to go 2-tier?

I only have ONE client now, so my multiple views are running under the same JVM; but it's time for me to begin to think about the next step.

Can you describe what you mean with your different tiers? Actually we didn't implement a two-tier architecture. We had our GUI-tier, a bussiness-logic-tier (both on client) and on server-side we just had our persistence-layer. We decided to go that way, because our client should react very fast to user-interaction so we didn't want to communicate to the server for each interaction.

Good question.

By 2-tier I mean a bunch of far (err, rich) Swing clients accessing the database directly.

3-tier, to me, involve some sort of an application server, with business objects running on them. A client still can be fat and do business logic, but it does not speak to the database directly.

I did not understand your solution, sounds like it was 2-tier by my definition? So, what do you (and others) think about my question: when is 2-tier a good idea? When not?

Hmm,

I think the solution to your problem would be to externalize the objects from Hibernate for use in memory by your Swing app. Then use mergeOrUpdate to put them back periodically.

When a Session is open you should "POJOize" your objects into the graph that you need. Whenever updates are made to these objects, you can then periodically open a session and use mergeOrUpdate to flush them to the DB.

We use exactly this pattern in Examinator - a reference application written by Terracotta. In Examinator we take some objects out of Hibernate for extended periods of time (much like your MVC in Swing). The only difference between our usage and yours is the fact that our app - Examinator - runs in a traditional 3-tier app. The interesting thing is that when you cut out the client and give the web application layer state it looks a lot like your 2-tier app.

And that's what we did - because holding long lived objects in memory is a lot lot lot faster than reading/writing them from/to the DB all the time.

(note that "POJOize" is term we made up - there are a few methods of stripping the Hibernate gunk from the objects it returns - we wrote a very very small library that does this in Examinator)