I'm using the related NHibernate project (a near direct port of Hibernate to .NET, though a little behind) and have encountered a locking problem that I think may be related to this one.

In my case, I'm using SQL Server which uses "SELECT ... FROM <table> WITH (updlock) WHERE ..." syntax instead of Oracle's "SELECT ... FROM <table> WHERE ... FOR UPDATE" syntax. When I do session.get(Class clazz, Serializable id, LockMode.Upgrade) for a joined subclass, it generates the following pattern:

SELECT ... FROM TraceObjects WITH (updlock,rowlock) LEFT OUTER JOIN VehicleObjects ON ...

This ends up with a "U" Upgrade lock on TraceObjects and a "S" Shared lock on VehicleObjects, effectively locking only TraceObjects. For me, this leads to a deadlock when NHibernate late attempts to UPDATE VehicleObjects which acquires an "X" Exclusive lock.

No I saw it stated in the NHibernate Users Group ("Dirty optimistic locking" https://groups.google.com/forum/?fromgroups=#!topic/nhusers/QbhORn71YKc) that subclass table locking is purposefully NOT done to avoid certain deadlock situations. But it appears that the Oracle dialect (or even Oracle's syntax?) is caused both tables in the join to be locked (a behavior I believe would solve my deadlock if I could get MS SQL Server to do that!), which violates the statement I found – not that the statement is sacred and true.

But what this means to me is that the MsSqlXxxDialects and OracleXxxDialects have very real differences in how locks are applied to the tables in a joined-subclass, and specifically for Oracle the locking differs on whether the lock is acquired during "get" or a later "lock".

It would seem the dialects should be consistent within themselves ("get" vs. "lock") and also consistent with each other (MsSqlXxxDialect vs. OracleXxxDialect).