[
https://hibernate.onjira.com/browse/HHH-1512?page=com.atlassian.jira.plug...
]
Steve Ebersole commented on HHH-1512:
-------------------------------------
Strong, but what happens with rs? My guess is that:
T1 : "select * from ck where id=3 with rr use and keep update locks"
would acquire and hold U lock on the ck.id=3 row
T2 : "select * from ck where id=3 with rr use and keep update locks"
would block, waiting on T1, since T1 already has a U lock on the ck.id=3 row
Also, if I understand correctly both (using rr or rs):
T3 : "select * from ck where id=3"
would acquire a read lock because U locks do not prevent concurrent read lock acquisition
If yes, then that is exactly the behavior we want here for UPGRADE lock requests.
Problem to lock a row in a DB2 database with LockMode UPGRADE
-------------------------------------------------------------
Key: HHH-1512
URL:
https://hibernate.onjira.com/browse/HHH-1512
Project: Hibernate ORM
Issue Type: Bug
Components: core
Affects Versions: 3.1
Environment: DB2 v8.2, Hibernate 3.1 and higher
Reporter: Peter Potthoff
Assignee: Steve Ebersole
Attachments: locks.txt
Original Estimate: 1h
Remaining Estimate: 1h
Using the LockMode UPGRADE to lock a row in the database, this will result in
a sql-statement: select ID from <schema>.<table> where ID =? and version =?
for read only with rs
This statement produces a shared lock and cannot be used for pessimistic locking because
this kind of lock won't stop a concurrent thread from accessing the data.
The source of the class DB2Dialect.java was changed from release 1.34 to 1.35:
http://cvs.sourceforge.net/viewcvs.py/hibernate/Hibernate3/src/org/hibern...
and from 1.33 to 1.34
http://cvs.sourceforge.net/viewcvs.py/hibernate/Hibernate3/src/org/hibern...
Please take a look at: HHH-378 and
http://forum.hibernate.org/viewtopic.php?t=954639&highlight=db2+lock+...
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira