[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-5275) Criteria.setLockMode does not work correctly

[Steve Ebersole (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44761#comment-44761 ] 

Steve Ebersole commented on HHH-5275:
-------------------------------------

Well, with regards to {{#setAliasSpecificLockMode}} in retrospect there is an assumption being made in terms of the generated SQL that maybe is not so valid.  To illustrate, I am not sure how valid something like {{query.setLockOptions(new LockOptions(LockMode.UPGRADE).setAliasSpecificLockMode("cat",LockMode.READ))}} is.  Probably this should obtain an exclusive lock (render a FOR UPDATE), but not sure what its implication in terms of whether or not to render the FOR UPDATE OF.

Going to push this to 4.0.2 (2 weeks) because 4.0.1 is scheduled for today and I would like to have some more dicussion/thought on this.

> 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.2
>
>         Attachments: AnotherOracle10gDialect.java, My_Oracle10Dialect.java, My_Oracle10Dialect.java, 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira