in memory, then after the update and before the application commit to the db, behind the scene, Hibernate does the second read against the current row on the database and get the image2, and then compare image1 and image2, if there is no difference, then the commit is allowed to proceed, otherwise, throw the "StaleObjectStateException".

Currently, as I know, many J2EE containers like Websphere and Borland Enterprise Server (BES) have alreadHi,

I am currently reading the "5.2.1 Using managed versioning" on the Hibernate in Action book. I have the following question regarding this optimistic lock implementation using the lock version or time stamp:

1. As the section mentions that "...For Hibernate managed versioning, we must add a new property to our Comment class and map it as a version number using the <version> tag...". In this case, it means the user of Hibernate has to do the followings in order to use this versioning support from Hibernate: must to define a properties in a persistence class and, to define a corresponsible field on the table.

I am just wondering, can all of these to be completely transparent to the user, say -- the end user doesn't need to define any additional properties or field for this purpose, instead just simply to specify something like "modifyVerifiedOptimisticLock" on the Hibernate mapping, and then, Hibernate will handle this transparently for the user?

I think this is possible, because before the update to take place, Hibernate could just first read in the current state of the row from database and get the image1 y provided this optimistic locking feature transparent to the user using their CMP entity bean implementation.

Do you have any comments on this or I may have misunderstood this issue? If so, please correct.


Thanks
Victor

Hi,

I am currently reading the "5.2.1 Using managed versioning" on the Hibernate in Action book. I have the following question regarding this optimistic lock implementation using the lock version or time stamp:

1. As the section mentions that "...For Hibernate managed versioning, we must add a new property to our Comment class and map it as a version number using the <version> tag...". In this case, it means the user of Hibernate has to do the followings in order to use this versioning support from Hibernate: must to define a properties in a persistence class and, to define a corresponsible field on the table.

I am just wondering, can all of these to be completely transparent to the user, say -- the end user doesn't need to define any additional properties or field for this purpose, instead just simply to specify something like "modifyVerifiedOptimisticLock" on the Hibernate mapping, and then, Hibernate will handle this transparently for the user?

I think this is possible, because before the update to take place, Hibernate could just first read in the current state of the row from database and get the image1 y provided this optimistic locking feature transparent to the user using their CMP entity bean implementation.

Do you have any comments on this or I may have misunderstood this issue? If so, please correct.


Thanks
Victor

I am very sorry that my two previous postings was somehow got screwed up by the notepad -- they were imcompleted and you please have to read both of them for the whole message:

So if you still have the patience, could you please read the my second message first and then read my first message.

Thanks a lot.
Victor

You can use various combinations of optimistic-locking=all/dirty and select-before-update=true

Micheal,

Could you tell me which option for the optimistic lock in Hibernate can free me from the need to define the additional properties i.e.: "version" in the persistence class?

I can tidy up the previous two posts and repost the complete message if you require (sorry for the mess).

Thanks
Victor

Use optimistic-lock="all" if you like a version comparision using all properties of your objects (ie. if you like to compare all fields in your rows, not only the version columns, on update and delete). Then, you don't need a version column, but you can't use the detached object/multiple Sessions strategy for long running application transactions (see Hibernate in Action for more info). You usually use a long running Session to implement your application transaction in this case.

You can however use optimistic-lock=all/dirty with detached objects if you use select-before-update=true, if I am not wrong?

Yes.

Chris,

I still can't really see why we can't just use the optimistic-lock="all" for the long running application transactions -- as each session is seperated from each other. ..

In another word, what is the difference between setting the optimistic-lock="all" and setting additional properties "version", regarding to the purpose of achieving the goal of optimistic locking? I think they should be the same.

I am just reading the Hibernate in Action -- the section of managing long running transaction using optimistic locking.

Chris, do I have any misunderstanding here? Please correct, thanks!! Or could you point me to the specific section of Hibernate in Action you are talking about?

Victor

[quote="christian"]Use optimistic-lock="all" if you like a version comparision using all properties of your objects (ie. if you like to compare all fields in your rows, not only the version columns, on update and delete). Then, you don't need a version column, but you can't use the detached object/multiple Sessions strategy for long running application transactions (see Hibernate in Action for more info). You usually use a long running Session to implement your application transaction in this case.[/quote]

You can not use optimistic-lock=all with detached object, because optimistic-lock=all needs the previous state of the object to compare to, and you don't have that for a detached object, unless you probably do select-before-update=true

but using optimistic-lock=all with 'select-before-update' would prevent detecting concurrency-situations! Because you're using the current db-content as 'previousState'! ...

The only possiblity to have a concurrency-check with detatched objects and no version columns is to cache a clone of the loaded object before changing values ... then reattach that clone and use 'saveOrUpdateCopy' ...

Therefore the version-column is the better solution ... you won't need a clone ...

gtx
curio

Uhm, yes. I think I've answered that wrong in another thread and Michael reposted it here. select-before-update is not useful here.

Ah yes, I faintly remembered select-before-update does not make optimistic-locking=all work for detached objects, but could not remember the reason ... Okay, I'll pin that to my monitor :)

I wasn't aware of the detached objects concepts until I saw you guys's discussion and checked out the hibernate section (which is a few chapters before the transaction section I just read).

To me, the detached objects looks like the orphans out of the session and reuse of them is one of the points hibernate is pushing on, I will read it further.

Without the context of the detached objects, then we can simply set the optimistic-lock=all and forget about the lock version stuff (lock version would cater for both situations though).