Hello,

I am writing a GUI client side app and have persistent objects in multiple sessions. i am trying to figure out the best way to notify duplicate objects in different sessions of updates\deletes etc so that the gui can perform refreshes.
does anyone have any suggestiongs? i don't really want to have to maintain some sort of cache of objects as i see this causing problems. does hibernate provide any existing feature that i could use?
thanks
cam

The Session _is_ a cache and you certainly don't want to notify Sessions of changed objects. A Session should have the lifetime of a single Transaction, hence the isolation.

i think you missunderstand, i'll use an example:

Session A has a persistent object Cat which is loaded and used by the gui.
Session B loads the same object, modifies it and then saves it.

What i was interested in was the best way to inform Cat in Session A of the update after transactions have been taked into account and the updated Cat is confirmed.
thanks
cam

We call that "application transaction". Bascially, you load a Cat in a database transaction A and send it to the UI. After some time, the user clicks "OK" and the Cat should be saved, this requires a second database transaction B.

In B, we perform a version check (using a version column or a timestamp) to ensure that no other concurrent modification happened to the Cat meanwhile. If it has been modified, we notify the user or simply overwrite it (various possible strategies here). This is called an "application transaction with versioning".

Each database transaction, A and B, uses a new Session. Once the Cat is loaded and sent to the UI, it is "detached" from the Session and doesn't know anything about the Session. The Session is closed and there is no way to "notify" other Sessions about a change.

This scenario is also covered in the reference documentation.

You may also use a notify/observer pattern to achieve what you want, but this is even more complex. The concept of detached objects is nothing new for Hibernate (more than 1 year old feature), but it seems Java developers need some time to grasp the power of it. Even the Cocobase guys market it now as a cool new feature with the "sessionless persistence" buzzword.

Cam,

If I understand clearly your problem, your application uses several Hibernate sessions to fetch data and send it to the UI layer.

For example, the user clicks on a button and a window opens showing the details of the Cat object. The user clicks a second time, and a new window appears with the same details.

Now the user modifies the Cat object in one window and save it.

What you want is the application being informed of the changes so it can refresh the display in the other window - keeping all your windows synchronized.

If I'm correct, then it is more an application architecture issue rather than an Hibernate specific problem.

I can see two solutions:

1/ Use a single Hibernate session
With a single Hibernate session, you will always get the same Cat instance back. So the two windows above will render the same instance. If your data classes - persisted by Hibernate - implements some kind of ChangeEvent, then you can keep your windows informed.
You can disconnect the session between requests - as proposed by Christian.
I can see one important issue with this approach: you have to purge the Hibernate session at some times, otherwise you may run out of memory...

2/ Hibernate Interceptor to propagate ChangeEvents
Another possibility would be to register an Hibernate interceptor that would broadcast ChangeEvent when an entity is updated.
The ChangeEvent would contain some information to identity the entity that has been modified.
Your windows (or other kinds of controler) would register for the ChangeEvent. In the example above, the second window will be informed of the modifications made on the Cat instance when the user commit his changes.
Possible issue: possible threading issues - make sure changes are committed on the database before fireing the ChangeEvent - otherwise, listeners may execute before Hibernate got a chance to do its work.


Hope this helps...