Criteria.setLockMode does not work correctly
Description
Attachments
cloned from
is duplicated by
Activity
Steve Ebersole January 11, 2012 at 8:11 PM
Prepping 4.0.1
Steve Ebersole January 10, 2012 at 1:20 AM
For 4.0.1 I just did the simplest thing that works (thanks Jakob!). Moving forward, I think these APIs should get cleaned up a little so I created to follow up on this issue on that front.
Graeme Rocher January 6, 2012 at 11:06 AM
@Steve - I understand it is not easy, and if you don't feel it is a reasonable request then there is nothing I can do. However, note that this is a regression of previous behavior that worked in 3.3.x.
In addition upgrading to Hibernate 4 is non-trivial both for us and Grails users as it has several breaking changes to the package structure. We are going to have to maintain 2 separate hibernate plugins, one for Hibernate 3 and another for Hibernate 4 so that existing Grails applications have an upgrade path.
I am happy to submit a pull request to fix the issue in the 3.6.x branch and collaborate on the fix if that helps. If not then I guess there is nothing I can do and Grails users will have to live with this broken functionality.
Steve Ebersole January 6, 2012 at 12:15 AM
The developer meeting is held on IRC, #hibernate-dev on freenode. You just have to be a registered freenode user.
I understand what you want. But as a developer I am sure you also understand the unworkability of maintaining bug fixes for all versions you have ever released. Thats simply not scalable. We would do nothing else ever but backport fixes between our various release branches.
Graeme Rocher January 6, 2012 at 12:02 AM
Steve - I'm mainly after the fact that "FOR UPDATE" is broken since Hibernate 3.5, so if that can be fixed in 3.6.x it would be much appreciated. How do I join the developer meeting btw?
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.