[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-5275?page=c...
]
Steve Ebersole commented on HHH-5275:
-------------------------------------
Hmm, I misremembered. Its the other way around. Setting alias specific lock modes was
the legacy Hibernate means in terms of HQL. JPA2 said that there is a single lock mode
associated with the query.
And given that we do not really have any tests apparently of the actual resulting behavior
of alias specific loicking I guess we get to make it up as we go! :)
One thought is that it is almost as if the the aliases being specified here are the FROM
clause aliases to lock *if* the lock mode is any form of PESSIMISTIC*. Like the lock mode
associated there should be irrelevant.
Essentially I am saying we might even want to revisit
{{LockOptions#setAliasSpecificLockMode(String,LockMode)}} and instead make it something
like:
{code}
/**
* Provided the lock mode associated with this set of options is a pessimistic lock, add
a
* query alias to specifically be locked in the resulting SQL.
* ...
*/
public LockOptions addAliasToLock(String alias) {
...
}
{code}
The idea being, these aliases would be the ones to show up in the FOR UPDATE OF.
Criteria.setLockMode does not work correctly
--------------------------------------------
Key: HHH-5275
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-5275
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.5.2, 3.5.3
Environment: Hibernate 3.5.2, Oracle 10 (using
org.hibernate.dialect.Oracle10gDialect
Reporter: Björn Moritz
Assignee: Steve Ebersole
Priority: Minor
Fix For: 4.0.1
Attachments: AnotherOracle10gDialect.java, My_Oracle10Dialect.java,
My_Oracle10Dialect.java, TestCase.zip
Time Spent: 2h 19m
The LockMode set via Criteria.setLockMode does not generate a ' for update' SQL
statement. In the org.hibernate.dialect.Dialect class only the LockOptions are used for
determining a possible addition to the SQL statement if using pessimistic locking. This
behaviour is different from Hibernate 3.1.3.
In the supplied TestCase two threads are reading the same database record; one of those
threads should use pessimistic locking thereby blocking the other thread. But both threads
can read the database record causing the test to fail.
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira