Is it Possible to Combine Hibernate + Swing?????

Question

Hi Xperts,
Is it possible to combine Hibernate + Swing?
(My Point of View Hibernate Contains Transaction, Session... But In Swing Session??????)
So i have lot of confusions.
SO
if Hibernate + Swing
IF YES. HOW? ELSE TELL THE REASON.
I EAGERLY WAITING FOR YOUR REPLY
Thanks
Edward and Hari

Answer 1

Hi Duffymo - thanks for responding. It's fun to discuss this with somebody; I don't usually get many reasonable/friendly responses on the Hibernate user forum.
What I mean by transaction based identity is thatin
the normal, recommended Hibernate process (one
session per transaction), objects fetched in
different transactions do not == each other. Solet's
say I do the following:
* Start session 1 and transaction 1, fetch object
with primary key 5, and store it in variable obj1.
Commit transaction 1 and close session 1.
* Start session 2 and transaction 2, fetch object
with primary key 5, and store it in variable obj2.
Commit transaction 2 and close session 2.
* At this point, even though they represent thesame
row in the database, obj1 != obj2. I'll assume you mean !obj1.equals(obj2)here, because [obj1 != obj2[/code] even without
Hibernate if the two references point to different
locations in memory in the same JVM. The equals
method can be overridden. You can decide to check
equality only examining the primary keys, or you can
do a field by field comparison. If the class checks
equality on a field by field basis, the only way
they'll not be equal is if you change values.I really do mean == in this case. If those two fetches happened within the same session, Hibernate would return the identical object from it's cache. Here's some pseudo-code illustrating what I mean:
Session firstSession = sessionFactory.openSession(); //Start an empty session
Transaction tx1 = firstSession.beginTransaction();
Object obj1 = firstSession.get( Person.class, new Long(5) ); //Fetches row 5 from the database
tx1.commit();
Transaction tx2 = firstSession.beginTransaction(); //Start a new database transaction, but still use the same session cache.
Object obj2 = firstSession.get( Person.class, new Long(5) ); //Just returns the same object it previously fetched
tx2.commit();
obj1 == obj2; //Returns true, because we're pointing to the exact same objects
obj1.equals( obj2 ); //Obviously returns true since they're pointing to the same object
Session secondSession = sessionFactory.openSession(); //Start an empty session
Transaction tx3 = secondSession.beginTransaction(); //New transaction in the empty session, no cached objects
Object obj3 = secondSession.get( Person.class, new Long(5) ); //Returns a newly created object, not in our session cache
tx3.commit();
obj1 == obj3; //Returns FALSE, these are two separate objects because they were fetched by different sessions.
obj1.equals( obj3 ); // Depends on whether the database row was modified since we fetched obj1
It sounds like you want an Observer pattern, where
every client would deal with a single model and
changes are broadcast to every registered Observer.
That's just classic MVC, right? In that case, every
y client might have an individual view, but they're
all dealing with the same model. Changes by one is
reflected in all the other views in real time.That would be awesome, but doesn't seem feasible. Our Swing clients are spread all around the world, and creating a distributed event notification system that keeps them all in sync with each other sounds very fun but extremely out of scope for this project. We're trying to make Hibernate manage the object freshness so that our Swing application clients may slowly become out of date, but when we trigger certain actions on the client (like a user query, or the user clicking a 'refresh' button) they refresh portions of their data model from the central shared database.
>
The reason that this is pertinent is because Swing
expects objects to be long-lived, so that they canbe
bound to the UI, have listeners registered withthem,
they can be used in models for JTables, JLists,etc.
In a typical complex Swing application, your only
choice is to use a very long-lived session,because
it would break everything if you were getting
different copies of your data objects every timeyou
wanted to have a transaction with the database. As
shown above, a very long-lived session will leadto
very out-of-date information with no good way to
refresh it.Maybe the problem is that you don't want copies of
the data. One model. Yes?One data model with real-time updates between all the connected clients would be ideal. However, I don't think that Hibernate is designed to work this way - it's really not even a Hibernate issue, that would be some separate change tracking infrastructure.
Realistically, what I was hoping for is that we could have a single long-running Hibernate session so that we're working with the same set of Java objects for the duration of the Swing application lifetime. The problem that I'm running into is that Hibernate does not seem structured in a way that lets me selectively update the state of my in-memory objects from the database to reflect changes that other users have made.
Certainly you've used JDBC. 8) That's what
Hibernate is based on. TopLink is just another O/R
mapping tool, so it's unlikely to do better. JDO
doesn't restrict itself to relational databases, but
the problem is the same.You're right, I have used JDBC, in fact we wrote a JDBC driver for FileMaker Pro so I'm pretty familiar with it. What I meant is that I've never tried using raw JDBC within a Swing application to manage my object persistence.
I have not used TopLink and I haven't heard much about it, but I did see some tidbits on an Oracle discussion board comparing Hibernate with TopLink that made it sound like TopLink had better support for refreshing in-memory objects. Not having used TopLink myself, I can't say much else about what it's strengths/weaknesses are compared to Hibernate. It's not really an option for us anyway, because you have to pay a per-seat licensing charge, which would not work for this project.
I know almost nothing about JDO except that it sounds really cool, is pseudo-deprecated, and it's probably too late for us at this point to switch our project to use it even if we wanted to.
I don't think the problem is necessarily the
persistence; it's getting state changes broadcast to
the view in real time. It's as if you're writing a
stock trading app where changes have to be made
available to all users as they happen. Fair?Yes, I agree that the core issue is getting state changes broadcast to the view, but isn't that within the responsibility of the persistence management? How are we supposed to accomplish this with Hibernate?
An excellent, interesting problem. Thanks for
answering. Sincerely, %Likewise. I would stress again that I'm not anti-Hibernate in general (well maybe a little, but that's mostly because of bad attitudes on the support forums), I just have not found a way to make it work well for a desktop GUI client application like Swing. Thanks for your help, and I would love to continue the conversation.