Can Hibernate be used with shared databases?
How does it behave? At our last integration project we chose Castor only because it has the notion of Long Transaction. Before a Long Transaction ends, Castor "refreshes" the cached object from the persistent storage and compares the user object against the fresh one. This way even if another application separately uses the storage we will still have data consistency.
Thanks.

Thats a very primitive approach to long transactions and optimistic concurrency. Hibernate uses a single UPDATE statement together with a version check and will throw a StaleObjectException if it has been modified in between. Hibernate has extremely flexible support for long "application transactions".

Thanks fot the prompt reply.
I have to add something on my previous question which states the problem more accurately:
As far as I understand, the hibernate persistent object must contain a serial which is stored in the database.
But, the database is NON MODIFIABLE and concurently managed by NON JAVA (AS400-ACG) applications.
Does it still work?
Thanks twice.

If non modifiable mean no schema update, then a lot of people succeed in using Hibernate on a legacy system (using composite-id for example).

You'll have to be more specific to have a more accurate answer

Ok. I'll Describe the problem entirely:

Most of our important projects are aimed to partially wrap and extend existing legacy applications without impacting on the functionality of the old system. For some very specific reasons we cannot wrap and substitute the entirely working apps.
For example we had to build a java document management system that wrapped 70% of the existing application that is written in ACG on AS400 and DB2. The ACG application must still work because the remaining legacy part (Warehouse Office) shares the data with the wrapped part (Purchases Office).
We could create tables only for the new features that were not existing in the old apps, while keeping the rest of db funtionality identical and completely compatibile with the ACGs.

So, when someone loaded a document that maps to legacy data, modified something and then pressed "Save" we had to be sure that we have modified the latest version of that document., because in the meanwhile some ACG user of the warehouse office could have modified that data.

The problem here is that we still need to take advantage of the persistence engine's cache, that shoud somehow "know" that the data has been changed in the underlaying db. Some kind of invalidation without external trigger. This was possible with castor only because on a "LongTransaction" update it reloaded the object's data from db prior to updating it, throwing an ObjectChangedException if the cache and the reloaded data were different.
This way we could assume that most of the time till the expiration of the cached object only our app would use that data. In the extreme case of conflict the user had to press 'refresh data' and lose her changes to the document while in the cache there would be again fresh data.
While castor is limited on some topics that we consider for future use we are still looking for a viable alternative.

What I was asking it was if there is such a mechanism of using hibernate with caching enabled and shared legacy DBs which are non structurally modifiable.

See optimistic-lock attribute, looks like it can detect conflict without altering database with version field. But I think you will not break legacy applications, if you will add version field to table too (just test it).

It'll break it since legacy apps, don't update the version column when they update.

Unfortunately it's impossible, as the legacy apps don's use SQL but native apis to access the data, they do not read records and tables as usually but pointers to data, so a new column could crash the system. Instead I was thinking of creating a new table for every legacy table to put the versionID, and map the object to every pair of tables.
While this resolves the extension problem it still does not resolve the data staleness when data modified externally for the reason stated by emmanuel. Do you thing that we could directly configure / modify in some aspect the persistence engine to fit this requirement?
For example by doing an update in which you put all the fields in the where condition instead of only the id and version? If no records affected=>stale data=>exception. The search performance would be not an issue as usually the databases search first for the first field in the where condition (PK) which is fast, and then for the others.
Any idea?

Guys, Juozas is right.

You can use optimistic-lock="all" or optimistic-lock="dirty" and then you don't need a version column.

I always forget that feature

Arh, me too ... I will tatoo it on my head or something :)

;)

Thanks a lot guys!
This is great, I'll definitely give it a try.

It remains only to make sure that we can implement a fully distributed solution using hibernate + cache in cluster.
Some specific docs or suggestions on this?
Thanks again.

You don't need distributed cache (you legacy apps will invalid such a choice)