[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-6125) Hibernate Criteria.setLockMode have unexpected behaviour when used in conjunction with MySQL

[Darryl Miles (JIRA)]

    [ https://hibernate.onjira.com/browse/HHH-6125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=45988#comment-45988 ] 

Darryl Miles commented on HHH-6125:
-----------------------------------

I too have found this problem when inspecting the SQL output of show_sql=true

I altered my pom.xml of my application provide to wind back the Hibernate versions and found that this is became broken in 3.5.0-Final and last worked in 3.3.2.GA of hibernate-core.  When I wound the version back core=3.3.2.GA, so added annotations=3.3.1.GA and entitymanager=3.3.2.GA and I see "select ... for update" in the show_sql=true output.

I did not test 3.4.x as I did not find it in Maven.

I believe Scott Marlow did some work to deprecate LockMode.UPGRADE and introduce some extra new modes at around this time, so that more fine-grained behavior could be provided.  This change set appeared to break support completely.

> Hibernate Criteria.setLockMode have unexpected behaviour when used in conjunction with MySQL
> --------------------------------------------------------------------------------------------
>
>                 Key: HHH-6125
>                 URL: https://hibernate.onjira.com/browse/HHH-6125
>             Project: Hibernate ORM
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 3.6.2
>         Environment: Hibernate 3.6.2, MySql 5.1
>            Reporter: Eric Poitras
>            Priority: Minor
>         Attachments: TestHibernate.java
>
>
> You expect hibernate to issue a select ... for update when issuing a Criteria of this form:
> // This fails
> Criteria c = s.createCriteria(SampleEntity.class);
> c.setLockMode( LockMode.PESSIMISTIC_WRITE );
> SampleEntity e = (SampleEntity) c.uniqueResult();
> But the MySQL dialect class simply ignore the lock mode per alias since MySQL does not support a per-table locking strategy. However, in the previous case, 
> it should issue a for update since we access ALL query tables in update.
> Also, since pessimistic lock may be critical for some process synchronization, it should AT LEAST not silently fail.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira