The EJB3-persistence-spec requires that LockModeType.READ and LockModeType.WRITE acquire physical database update/exclusive locks for the duration of the current transaction. Currently we have mapped LockModeType.READ to LockMode.UPGRADE and LockModeType.WRITE to a new LockMode.FORCE (LockMode.FORCE essentially acts like LockMode.UPGRADE in the case of non-versioned entities).
However, this is problematic in the way we currently apply locks against databases which do not support some form of "SELECT ... FOR UPDATE" (Sybase, SQLServer, and DB2 use different semantics, but are OK here). The dialects in question here are FrontBaseDialect, HSQLDialect, MckoiDialect, PointbaseDialect, RDMSOS2200Dialect, TimestenDialect (AFAIK, HSQLDB does not even support read-committed, so lets not even consider this one in this discussion). On these dialects, we currently silently fall back to not specifically acquiring any type of lock. The first question here is whether that is correct behavior. I'd actually be more inclined to throw an exception moving forward if the user requests a lock mode for which we cannot guarantee acquisition. However, this will cause compatibility issues for users relying on that old behavior. Secondly, EJB3 only requires that we actually support its version of lock() for versioned entities, but that we absolutely need to support it on versioned entities. That means that for the dialects mentioned above we need to do something different in order to acquire the appropriate database lock. The natural choice here is to perform an update to force an update or exclusive lock in the database. The question here is whether we should support this only for versioned entities, or whether we should expand this to include non-versioned entities as well in our implementation. If we choose to expand this support to non-versioned entities, the question becomes what columns do we update in order to acquire the lock? So, for LockMode.UPGRADE: 1) Should this be an error if we cannot guarantee a write lock in the database? Again, I say yes. 2) To what extent should we attempt to guarantee a write lock? Only in the case of versioned entities? Expand to non-versioned (and how)? ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
