[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-2152) Optimistic lock error although using LockMode.UPGRADE

[Ameer Antar (JIRA)]

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

Ameer Antar commented on HHH-2152:
----------------------------------

Yes, this is a serious problem. There is a method on session called:

	public void lock(Object object, LockMode lockMode) throws HibernateException;

You lock a persistent object, that's what lock on class means. Should be obvious. The only work around I found is to do a flush after a subclassed object is modified. 

> Optimistic lock error although using LockMode.UPGRADE
> -----------------------------------------------------
>
>                 Key: HHH-2152
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2152
>             Project: Hibernate3
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 3.1.3
>         Environment: Oracle 10.2, Hibernate 3.1.3
>            Reporter: Per-Olov Wingren
>            Priority: Minor
>         Attachments: OptLockProblem.zip
>
>
> I have a situation where two threads tries to update the same entity object at the same time. I use the Hibernate managed versioning using a version number but also a pessimistic lock using LockMode.UPGRADE.
> One thread will lock the object in the database and the other will wait for the transaction of the first thread to commit (or rollback). The first thread updates the object, which also will make its version to be incremented. When the second tread get access to the object after the first is commited, it get an incorrect value of the version attribute. This leads to a StaleObjectStateException when the transaction is commited.
> The entity object conists of a parent class and a subclass mapped to the database into two tables using <joined-subclass>.
> If the testcase is modified to update an attribute in the subclass (numberB) instead of in the superclass it works without errors. Is the problem caused by the fact that Hibernate only locks the subclass in the database (for update of classb.oid) and not the superclass?
> I attache a zip file containing a simple but complete test case that shows the problem.

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