Ive recently started on a project and the existing physical architecture is to have a DB on the server and a (single) client on a seperate machine with hibernate on the client talking to the server over JDBC.

While this works fine for one client, we will be adding multiple clients (covering different business functions) very soon now. I am in the process of forming an argument to push for having a single instance of hibernate on the server since this is the way I (and everyone else Ive ever talked to previously who has used ORM systems) have always done it previously.

It seems that from a theoretical point of view that multiple instances of hibernate sharing a DB can be made to work by configuring it appropritely e.g. disabling the cache and forcing optimistic versioning via DB column, but it seems inherently fragile to me.

Has anyone tried doing this before ? or can anyone point to specific hibernate behaviour that would completely rule this out as a viable approach ?.

I guess Im also asking whether this architecture is viable going forward in terms of hibernates design philosophy - if it does not do so already, is hibernate likely to introduce assumptions about whether the underlying database can be externally updated.

Thanks,

Paul.[/i]

This is exactly the same situation as having multiple client types access the same database (whether the "other client" be a COBOL process or a C++ program, etc).

Yes, many people use Hibernate in such "shared access" scenarios.

You do not necessarily need to disable second level caching to make such an approach work. The most common caise is to use clustered caching. But even outside of clustering, it depends on whether the various processes update the same data and their sensitivity to staleness.


Absolutely not. It would not really make sense to do so. Relational databases are designed to handlle such access patterns, and Hibernate is all about allowing users to harness the power of RDBMSs while simplifying the programming moddel needded to work with them.

Thanks for the response.



Id like to try to bottom this out if I may.

Lets assume that I dont want to configure second level cache clustering (these are independent clients rather than say a replicated server farm).

I presume that with a new session all data read during the session would at least as current (with the underlying DB) as the time of starting the session.

I also presume that data *may* become state in the session if the DB was updated externally after the start of the session, but such staleness would be caught by appropriately configured optimistic locking (either full table or version column).

Is there a means to force an optimistic lock check *without* commiting a transaction ? (lets say I wanted to actively warn users that they are potentially looking at stale data if they were in the middle of an update).

Thanks,

Paul.
[/quote]

Sure. Just use Session.lock() with LockMode.READ. Check the manual/api-docs...

OK the last (I think) remaining thing Im trying to get my head round on this subject is the precise granularity of DB updates.

From a combination of reading the docs and the source code I have managed to glean the following:

Session.getTransaction() and Transaction.commit() map to underlying DB begin/commit except where either a) FlushMode.NEVER is set, or b) the session maps onto some form of external transaction managment such as JTA.

However Im not entirely confident Ive worked this out correctly because the docs seem ambiguous:

From Session.flush():


This statement seems contraditory - "Must be called at the end of a unit of work" is surely false if "Transaction.commit() calls this method" (which indeed it does in the actual code).
I think I know whats its getting at but when I see the phrase "Must be called" in an API doc then I naturally assume that it means *I* must call it and I am assuming that I do not, and further more Im assuming that setting FlushMode.NEVER and manually calling flush() to batch up multiple hibernate transactions into one DB write is not a bonafide use of flush() in a JDBC environment.

Thanks,

Paul.