Hi,

My team and myself are currently getting familiar with the ORM world and we surely begin to appreciate what Hibernate has to offer.

We're currently testing Hibernate for a JSP-Struts-Hibernate application (with all the proper encapsulating layers between these three components). On of the actions this application needs to accomplish is the edition of reference relational tables (which all have primary keys generated through sequences). The idea is to:

1) Display all the objects (basically, records) from a given table (basically, perform the equivalent of a "select * from TABLE").
2) Have a user select one of these objects to update/delete it.
3) Persist the changes in the database.

Pretty basic so far. One difficulty we have comes when concurrency is involved. As for example, we encounter a situation where two users (UserA and UserB) work on the same table; they both have the same list displayed in front of them and UserA deletes an object while UserB tries to update it: a simple session.update() called by UserB through Hibernate will not be a good thing since basically it will try to update a record no longer part of the database (and it will not return any exception since basically no exception occured). Do we encounter this situation because we do not use Hibernate properly? Should we rely on pessimistic locking strategies? Before updating an object, should we first make sure that the object still corresponds to a record in the database? Does Hibernate provide usual mechanisms to do so?

The questions above might simply show how new we are with Hibernate (but, hey!, ain't that what a Beginners forum is for?) but any guidelines, references, hints, tips, comments, etc. would be greatly appreciated.

Thanks,

Hibernate should throw an exception in this case, since the JDBC rowcount will be 0, instead of the expected 1. (As long as jdbc batch updates are disabled.)

But of course! We did overlook the hibernate.jdbc.batch_size property; by setting it to 0, Hibernate indeed throws an exception, which, when caught, can allow us to work on that.

Thank you very much!

I have the slightly different problem with concurrency. When userA deletes the record and userB updates it, I get an error. My problem is when userA updates the record and userB updates the record later, userB overrides the change made by userA. But I should get a StaleObjectError when userB updates the record.
I am using the technique mentioned in the reference document 14.3.2 (Many sessions with automatic versioning). I do use saveOrUpdate, then flush, commit and close. Is there any additional steps or am I doing anything wrong.

Thanks for your help.

Optimistic locking is the solution to your problem. (A version column is added to the DB table.
Use the version tag of class (section 4.1.7 of the reference guide).

User A gets the version n,
User B gets the version n
User A updates the object and version is be incremented by Hibernate to n+1
User B updated the object and Hibernate tells that version number n != n+1 => exception is raised and no update is done.

I am trying to implement, Many Sessions with automatic versioning (14.3.2 of reference guide) for optimistic locking. What properties need to be set in the mapping file to implement this technique.
You mentioned the Application version checking (14.3.3 reference guide) technique. But in the reference guide, it is mentioned, that this is the least effective method. So I am trying to implement the 14.3.2 method.
Could you help me, in implementing 14.3.2, I don't know what needs to be done in the mapping file to implement it.

Thank you very much for your help.

You just need a <version> or <timestamp> property.

Don't forget to update your db schemma too... (add a column named version to the table that maps to your entity)