[Hibernate-issues] [Hibernate-JIRA] Commented: (HB-468) handling of version checking in optimistic transactions

[<leg...@at...>]

The following comment has been added to this issue:

     Author: Panagiotis Louridas
    Created: Thu, 13 Nov 2003 7:42 AM
       Body:
Thanks Gavin,

You are right; I should have checked. Sorry if my mail seemed offensive in any way. I had an impression that perhaps hibernate were using some internal versioning mechanism on its session-level cache, and that the programmers were on their own concerning optimistic transactions.

Sorry again. We are a big Greek investment bank and a big development project was saved thanks to hibernate. We develop on hibernate daily for almost a year, and we definitely have had no reasons to believe hibernate's developers stupid.

Best Regards,

Panos
---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-468


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-468
    Summary: handling of version checking in optimistic transactions
       Type: Bug

     Status: Closed
   Priority: Major
 Resolution: REJECTED

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0 final

   Assignee: 
   Reporter: Panagiotis Louridas

    Created: Thu, 13 Nov 2003 3:19 AM
    Updated: Thu, 13 Nov 2003 5:40 AM

Description:
Taking the example given in 14.3.3 of the reference manual,

// foo is an instance loaded by a previous Session
session = factory.openSession();
int oldVersion = foo.getVersion();
session.load( foo, foo.getKey() );
if (oldVersion!=foo.getVersion ) throw new StaleObjectStateException();
foo.setProperty("bar");
session.flush();
session.connection().commit();
session.close();

it is possible that the version check will succeed and yet stale objects will be persisted in the database. Consider two clients A and B, running the above code concurrently. Suppose we have their actions are interleaved in the following way:

A: session = factory.openSession();
B: session = factory.openSession();
A: int oldVersion = foo.getVersion();
B: int oldVersion = foo.getVersion();
A: session.load( foo, foo.getKey() );
B: session.load( foo, foo.getKey() );
A: if (oldVersion!=foo.getVersion ) throw new StaleObjectStateException();
B: if (oldVersion!=foo.getVersion ) throw new StaleObjectStateException();
A: foo.setProperty("Abar");
B: foo.setProperty("Bbar");
A: session.flush();
A: session.connection().commit();

at this point, the object read by client B is stale. Still, B will proceed with

B: session.flush();
B: session.connection().commit();

as if nothing had happened.

I surmise that hibernate produces SQL update code that updates the database tables using the id of the persisted object:

UPDATE ... WHERE id = ...

The above issue would be resolved if the SQL update code also contained a version equality test:

UPDATE ... WHERE id = ... AND version = ...

Best Regards,

Panos Louridas.


---------------------------------------------------------------------
JIRA INFORMATION:
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

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira