[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-2392) LockModes referencing non-root joined-subclass class in HQL/Criteria
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2392?page=c...
]
Steve Ebersole commented on HHH-2392:
-------------------------------------
Actually to be completely friendly in terms of concurrent non-HIbernate access, all tables
in the hierarchy should be locked because we do not know the order in which the
non-Hibernate access will attempt to perform updates. That, however, given the current
state of the HQL and Criteria translators is extremely difficult (well Criteria is
somewhat doable).
LockModes referencing non-root joined-subclass class in HQL/Criteria
---------------------------------------------------------------------
Key: HHH-2392
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2392
Project: Hibernate3
Type: Bug
Components: core
Environment: dialects supporting FOR UPDATE OF construct (Dialect.forUpdateOfColumns()
== true)
Reporter: Steve Ebersole
Assignee: Steve Ebersole
Fix For: 3.2.3
When setting a LockMode to an HQL or Criteria query where the lock applies to a non-root
subclass in a joined-subclass hierarchy, the result is incorrect on dialects which support
the FOR UPDATE OF construct. The problem is that logically, the root table should be
locked; however, the "driving" table is instead locked currently.
For example, consider:
Person
|
-----------------
| |
Employee Customer
For queries against Employee requesting that Employee be locked, the physical DB lock
should actually be applied to the Person table!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira