Hi,

I have a question about how Hibernate works in this scenario.

I am developing a set of separate applications that all access the same database. These applications are a mix of web based and stand alone Swing applications, each using their own SessionFactory. All these applications share acess to a single database.

Since Hibernate uses Proxy objects and advanced caching tecniques, I am wondering what happens if an object that is cached in the SessionFactory of application A is updated by the SessionFactory in application B.

Will the cached copy of application A be updated, or will it still use the old data from the memory cache rather than re-querying the database?

Thanks in advance for your help

depends on the caching layer you use,

some of them you can configuere to be aware of the other "hibernate sessions" on other machines (i think there are some clustering faq's).

When you use thme you get an automatic flush on machine B when machine A updates an entry cached by B.

So it basicly comes down to the network layout where the hibernate instances live on. can the webapps communicate? or are there firewalls between them ?

Unless you spend time on working with caches, each Hibernate Session is 'separate', and it uses it's own universe, from identity map to caches.

Hence, changes made (and commited) in one session are not 'visible' to another session(s) - even within one Java VM space talking to one database.

Normally (again, without extra work), Hibernate handles the problem of 'out of sync' Sessions by using Optimistic locking:

In simple terms, whenever Hibernate updates a database row (from one session), it bumps up the 'version'. Then, when any other Session which held the same data tries to update them, it fails with 'stale data' (as a simple example, Hibermate qualifies the update with 'where version=nn', and if the version has changed, it detects a failed update)

The main issue with caching is that, unless you explicitly refresh your object(s), your cached data will NOT reflect database changes.

But that is true even when you have just one Session, or even when you use just a plain JDBC: When some other process alters your database, your Session does not know about it -- unless you implement some change detection or notification mechanism.

(Don't forget to rate this posting - if it helped).

Just to be more specific, I said:


By this I meant learning how to select, configure and make-use-of secondary cache, starting with

Both Hibernate books devote fair amount of attention to this subject, but as always, in practice you end up learning a lot in the process...

In my experiences, caches are good ... IF you can guarantee that there is no other database access than thru your cache(s) ... which is where it often fails flat on it's face.

Then, the best use of your $$$ is usually making your SQL database server 'the cache', and give it more memory...

Thanks for your answer, I supposed it was something like that. I am wondering if a possible solution could be to use just one JNDI data source for all applications.