Hi,

I am working on a large (enterprise scale) project. I recently downloaded Hibernate 2.1 and read its documentation and examples. I still have couple of questions unanswered:

1> Entity Beans vs Hibernate:
- What does Hibernate have that Entity Beans can NOT offer?
- What do Entity Beans have that Hibernate can NOT offer?

I am particularly interested in ability to query or update tables from multiple databases (databases hosted on different database servers in different countries) in one EJB transaction.
(* An interesting thing is, some databases still don't support 2-phase commit.)

2> HQL / Database capabilities:
- Can you maintain foreign keys across databases using Hibernate classes?

- Does HQL support joining tables from different databases?

For example, assuming table1 in database1 and table2 in database2; will following query work?
SELECT table1.col1, table2.col2
FROM table1, table2
WHERE table1.col3 = table2.col3
Some databases like Oracle, MS SQL Server (and more) support cross database joins. But does Hibernate support it in HQL?

Thanks for your time,
- Hrishi

1. this is very long to answer so just some tips:
ability to test and run your application outside the J2EE container
ability to have a clean domain model (no link between the persistence engine and your domain model) : easy to test, easy to do batchs.
More portable code from one App server to another.

EJB Entities can be accessed remotly (just joking, this is not a + feature)

2. cross DB accesses and Joins, this feature is not natively supported by Hibernate. Of course if your underlying DB can do that, this will be transparent for Hibernate. BTW, using the DB cross join capability is probably the best option wether you use Hibernate or not (and I would say too, using cross join is not recommended at all)

actually what I've missing in Hibernate is pessimistic locking that comes by default in e.g. JBoss Entity EJB

to work around this, I've added "pessimistic-read-write" as just another caching strategy, with explicit lock on get() and releasing lock on afterUpdate() (as opposed to "read-write" strategy which retrieves locked item directly from database instead of blocking, as READ_COMMITTED isolation level)

threads trying to execute get() from cache will be blocked on wait() until notifyAll() happens in the thread that holds cache item lock

the benefit is that with that strategy changes to an instance of object are allowed for only one thread, without making rather expensive hits to database (select ... for update)

I'm going to test this thing soon under high load and could also submit it to Hibernate codebase, in case anyone is interested

Actually we strongly believe that lock in the middle tier is a huge mistake.
Gavin bloged on this topic.

maybe you could give me then an advice - how else it is possible to implement pessimistic locking without impairing performance by extra database hit and, effectively, by not using cache at all?

should it be something like

load( ... with lockmode NONE ) - object is taken from cache or loaded from

lock ( ... lock mode UPGRADE) - "select id from X for update" is executed and lock is made by database?

Hibernate delegate pessimistic locking to the Database. This is the only sure and efficient way to pessimistic locking.
Yes use the lock strategies to achieve that.

Yes, it is a very huge mistake and try to find the way without any locking (schema design helps in the most of cases) and let the database to control concurency. Concurency control is not so simple as "wait/notify", it can produce more deadlocks than to increase performance.

sorry, it's me again, about locking and caching and all that stuff

so what I've done to achieve both caching and locking

there are two objects
one is Lock and second is Data
Lock is not cached and loaded with LockMode. UPGRADE
Data is cached and loaded with LockMode.NONE

so far so good

transaction does to following:

1. acquire instance of Lock (select ... for update is done underneath, Lock is simple object thus this hit is inexpensive)
2. acquire instance of Data - it's taken from the cache
3. change Data
4. commit - SQL update is executed for Data and Lock

there are two problems with it:

first problem: not every database supports "select ... for update", namely free embedded Java databases like HSQL or McKoi - despide I do LockMode.UPGRADE, just normal "select" is done, and I get no locking I need... I'm just curious, how do the others do locking on such puny databases? is there more universal way to achieve locking?

second problem:
I've noticed interesting behaviour of ReadWriteCache

see
transaction 1 begins
transaction 1 tries to acquire Lock
transaction 1 acquires Lock
transaction 1 loads Data
transaction 1 goes on...
transaction 2 begins
transaction 2 tries to acquire Lock
transaction 1 commits
transaction 2 acquires Lock
transaction 2 loads Data !!! here ReadWriteCache says "Cached item was locked: ..." - so it hits database instead
transaction 2 goes on...
transaction 2 commits

apparently it's because an item has been put into cache by transaction 1 _after_ transaction 2 has been started, so transaction 2 is supposed to read data as it was before its start

can anyone give me a hint - how to make transaction 2 pick data from cache?