I am converting an app to use hibernate. The app has the main gui and several background threads providing synchronization to a centralized database (via web services NOT hibernate). So ther eis a local datbase that the app talks to via hibernate and another database that the app synchs too through web services (no hibernate).

Say I have Class as follows (all these fields are persisted)

MyClass
String fieldA
String fieldB

The gui opens a session and keeps that open throughout the entire user processing (10 to 15 minutes). When the processing is done the session is committed and closed.

Issues arise in the background thread. The main gui thread updates fieldA and the background thread updates fieldB. This was fine with my previous persistence engine since it would only incude "changed" fields in the sql update query.

Looking for recommendations on a way to do this with hibernate. As well as also seeing if I am thinking properly about how to use hibernate.

Here are my thoughts...


Option 1 - I could have a "global session" that the gui and background threads use. This will share the MyClass instances and properly handle fieldA being updated by the gui and fieldB being updated by the background thread. It will not allow for transaction isolation (which is not a big deal). The big issue as I see it is when to close the session. I could have a check that goes and makes sure no background threads are running and the gui is on the main menu (i.e. no objects in memory). Real big ick here but doable.


Option 2 - Use a session per thread and hand code the JDBC to update in the second thread. Strengths are this allows the transaction isolation. Weakness I was using hibernate to avoid hand coded jdbc. i.e. hand coded jdbc is fragile...


Optoin 3 - Use a session per thread on both the UI and the background thread. They boht use hibernate IO and some "unknown" mechanism to handle the multiple updates of the same persisted MyClass instance.

I can't see how multiple threads synchronization problems can be saved by only updating "changed" fields - but if that solves your problem then why don't you just tell hibernate to do so ? ;)

Look for dynamic-update and dynamic-insert in Hibernate2 docs.

My problem is the background thread updates fieldB while the gui has another instance of MyClass and it updates fieldA. The background commits it's changes. Later the gui commits it's changes and gets an error (StaleObjectException if I remember correctly) because the instance of MyClass has changed. My other option was to not use the versioning info which causes the gui to overwrite the change to fieldB.

The reason it used to work is the background thread would effectively do this.

update myclass_table set fieldB = "background" where uid = 12345


Then in the gui thread when it updated it would

update myclass_table set fieldA = "gui" where uid = 12345


This works because each thread is updating it's own field... Now when I use hibernate this happens

backgroudn thread does


update myclass_table set fieldA="originalValue", fieldB = "background" where uid = 12345

Then later the gui thread does this


update myclass_table set fieldA="gui", fieldB = "originalValue" where uid = 12345



Anyway I hope that explains it better. I will go take a look at dynamic-update now thanks :-)

that will do it nicely thanks alot for the quick response.....

So - to make this work you are completly relying on your coding skills and luck that you will never overwrite data!!?

That sounds very dangerous in normal systems :)

Yeah it does doesn't it LOL.... IT isn't as bad is it sounds as the fields and general deisgn of the system take care that the GUI can't update the backgroudn fields and vice versa. So generally it would require programmer discipline there are other mechanisms in place that make it safer than the example I gave.

But.... I just finished doing some experimentation and have it working where I have a single global session that both the background thread and the gui thread share. The only tricky part was knowing when to close the session (which I have an elegant solution via the tools from Doug Lea's concurrent package).



So a question is. Is it okay to have a session open for say 20 minutes? I am using a standalone hibernate database so no worries about the db connection going belly up and I do granular commits when the gui or background thread change something (they also both behave well with each other). Well the gui doesn't behave well it just does what it does but the background thread is sensitive to the gui and does it's commits in a way that works...

In other places I can still get a thread per instance session. I am using the HibernateSession from the docs and have

class HibernateSession {
public static Session currentSession( boolean useGlobalSession );
public static Session currentSession();
}


So if a thread starts a transaction it can decide if it wants to use the shared session or a session per thread by doing a

HibernateSession.currentSession( true ); // use the global session

subsequent calls to HibernateSession.currentSession() will returnt he global session....

For a thread to get a session per thread then they don't do anything since the default behaviour is session per thread. Or they can explicitly do a

HibernateSession.currentSession( false);


Does this sound reasonable? Any hidden gotchas?

None besides the obvious possible non-deterministic behavior ;)

that reminds me of ibm's famous phrase...

"unpredictable results may occur"....


Well I am going to go with it for now since I have live code that it simply not working right now an dthis will fix it. I plan on reworking this to work more in line with what the SpringFramework does when the fire is out...


Thanks for all your assistance...