[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-5275?page=c...
]
Dmitry Katsubo commented on HHH-5275:
-------------------------------------
I confirm the problem exists both for v3.2.6GA and for 3.6.0CR1:
* For v3.2.6GA the problem is perhaps in org.hibernate.loader.criteria.CriteriaJoinWalker,
lines 84 & 90: {{LockMode.NONE}} should be replaced by {{criteria.getLockMode()}}
* For 3.6.0CR1: the problem is in
org.hibernate.loader.criteria.CriteriaQueryTranslator#getQueryParameters(), line 277:
{{LockOptions}} are created but {{lockOptions.setLockMode()}} is newer called and the
specified lock mode for criteria is associated with {{this_}} alias, but does not affect
the resulting query.
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
Priority: Minor
Fix For: 3.5.x, 3.6.x
Attachments: TestCase.zip
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.
-
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