[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5275?page=c... ] Björn Moritz commented on HHH-5275: ----------------------------------- In the Query API there are two methods: setLockOptions and setLockMode. setLockOptions seems to work (as far as I can see from the org.hibernate.impl.QueryImpl class), but I did not test it. setLockOptions does not exist in Criteria API. -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5275?page=c... ] Björn Moritz commented on HHH-5275: ----------------------------------- The bug is also present in version 3.5.3 -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5275?page=c... ] Gail Badner updated HHH-5275: ----------------------------- Fix Version/s: 3.6 3.5.x -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5275?page=c... ] Steve Ebersole updated HHH-5275: -------------------------------- Fix Version/s: (was: 3.6.0.Beta1) 3.6.x -- 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

[ 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. -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5275?page=c... ] Steve Ebersole updated HHH-5275: -------------------------------- Fix Version/s: (was: 3.6.0) 3.6.1 -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5275?page=c... ] Jakob Braeuchi updated HHH-5275: -------------------------------- Attachment: My_Oracle10Dialect.java Oracle Dialect with workaround -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5275?page=c... ] Jakob Braeuchi commented on HHH-5275: ------------------------------------- there also is a difference in the generated sql: query.*setLockMode*("cat", LockMode.UPGRADE); generates "select ... *for update of this_.CAT_ID*" with hibernate 3.3.2 query.*setLockOptions*(new LockOptions(LockMode.UPGRADE)) generates "select ... *for update*" with hibernate 3.5.6 according to our oracle-specialist this makes no difference because both ways lock the whole row. to make setLockMode() work like setLockOptions() the method MyDialect#getForUpdateString() could look like this: {noformat} public String getForUpdateString(String aliases, LockOptions lockOptions) { LockMode lockMode = lockOptions.getLockMode(); Iterator<Map.Entry<String, LockMode>> iter = lockOptions.getAliasLockIterator(); while(iter.hasNext()) { // get highest LockMode Map.Entry<String, LockMode>entry = iter.next(); LockMode lm = entry.getValue(); if (lm.greaterThan(lockMode)) { lockMode = lm; } } lockOptions.setLockMode(lockMode); return super.getForUpdateString(aliases, lockOptions); } {noformat} actually the same logic could be applied to org.hibernate.LockOptions#setAliasSpecificLockMode(): {noformat} public LockOptions setAliasSpecificLockMode(String alias, LockMode lockMode) { aliasSpecificLockModes.put( alias, lockMode ); // set higher LockMode if (this.lockMode.lessThan(lockMode)) { this.lockMode = lockMode; } return this; } {noformat} this worked for the queries i was testing. but i'm not sure if this is the way LockOptions should work. -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5275?page=c... ] Gail Badner updated HHH-5275: ----------------------------- Fix Version/s: (was: 3.6.1) 4.0.0.Alpha1 3.6.2 -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5275?page=c... ] Steve Ebersole updated HHH-5275: -------------------------------- Fix Version/s: (was: 3.6.3) 3.6.4 -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5275?page=c... ] Gail Badner updated HHH-5275: ----------------------------- Fix Version/s: (was: 3.6.5) (was: 4.0.0.Beta1) -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5275?page=c... ] Graeme Rocher commented on HHH-5275: ------------------------------------ This is causing this issue in Grails http://jira.grails.org/browse/GRAILS-8433 Any chance of getting this fixed? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5275?page=c... ] Steve Ebersole commented on HHH-5275: ------------------------------------- So based on my experiments here is what I see... # get/load work as before. # {{Criteria#setLockMode}} did not work, neither form # {{Query#setLockMode}} did not work {panel} Jakob, with regard to the difference between * {{query.setLockMode("cat", LockMode.UPGRADE)}} and * {{query.setLockOptions(new LockOptions(LockMode.UPGRADE))}} I think that is valid actually. IMO, if you want to lock just a specific table you would instead say this in the second form: * {{query.setLockOptions(new LockOptions().setAliasSpecificLockMode("cat",LockMode.UPGRADE))}} This does not work either, but that is the behavior I will shoot for {panel} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5275?page=c... ] Steve Ebersole updated HHH-5275: -------------------------------- Fix Version/s: (was: 4.0.1) 4.0.2 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5275?page=c... ] Steve Ebersole commented on HHH-5275: ------------------------------------- To be honest, this "alias specific locking" stuff was all added to support JPAQL which defines support for this. I know its probably asking too much that a JCP spec actually be detailed enough to get into details like this, but I'll have to go back and follow whatever guidance they provide in this regard. I'll comment back with what I find. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5275?page=c... ] Steve Ebersole commented on HHH-5275: ------------------------------------- Just to clarify... I get the initial intent (I think) behind {{setLockMode(String alias, LockMode lockMode)}}. I do want to keep the added ability to be able to affect which tables to lock. And yes I understand that some databases do allow you to specify different lock parameters for different tables in a query. But I do not think that alias->LockMode gives us enough information anyway to be able to really leverage that. Hence why I suggest about simply tracking aliases to be locked. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5275?page=c... ] Chad Wilson commented on HHH-5275: ---------------------------------- @Steve Your addAliasToLock suggestion sounds reasonable. The current setAliasSpecificLockMode doesn't really feel natural and leads to weird use of the API ("why does it let me set this indeterminate combination of lock modes and aliases?") Also worth noting the couple of related issues to pessimistic locking/forUpdate I linked to this ticket (one is prob a dupe of the other) which might necessitate some re-jigging around the ordering of how it generates the various clauses. Not sure if that opens other cans of worms! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5275?page=c... ] Steve Ebersole commented on HHH-5275: ------------------------------------- Graeme, just to clarify, we also cannot address "alias specific lock mode" in 4.0.1 either for the same reasons. That would need to wait for 4.1. I guess what I am saying is that for 4.0.1/3.6.whatever-the-hell-we-are-up-to-now we could address that "FOR UPDATE" or whatever actually gets applied. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5275?page=c... ] Graeme Rocher commented on HHH-5275: ------------------------------------ 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? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5275?page=c... ] Graeme Rocher commented on HHH-5275: ------------------------------------ @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. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5275?page=c... ] Steve Ebersole commented on HHH-5275: ------------------------------------- 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 HHH-6954 to follow up on this issue on that front. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira