we have three ways to handle the concurrent attempts to write to the database:
■ Last commit wins—Both updates succeed, and the second update overwrites the changes of the first. No error message is shown.
■ First commit wins—The first modification is persisted, and the user submitting the second change receives an error message. The user must restart the business process by retrieving the updated comment. This option is often called optimistic locking.
■ Merge conflicting updates—The first modification is persisted, and the second odification may be applied selectively by the user.
The first option, last commit wins, is problematic; the second user overwrites the changes of the first user without seeing the changes made by the first user or even knowing that they existed. In our example, this probably wouldn’t matter, but it would be unacceptable for some other kinds of data. The second and third options are usually acceptable for most kinds of data. From our point of view, the third option is just a variation of the second—instead of showing an error message, we show the message and then allow the user to manually merge changes. There is no single best solution. You must investigate your own business requirements to decide among these three options.
The first option happens by default if you don’t do anything special in your application; so, this option requires no work on your part (or on the part of Hibernate). You’ll have two database transactions: The comment data is loaded in the first database transaction, and the second database transaction saves the changes without checking for updates that could have happened in between. On the other hand, Hibernate can help you implement the second and third strategies, using managed versioning for optimistic locking.
Using pessimistic locking
Locking is a mechanism that prevents concurrent access to a particular item of data. When one transaction holds a lock on an item, no concurrent transaction can read and/or modify this item. A lock might be just a momentary lock, held while the item is being read, or it might be held until the completion of the transaction. A pessimistic lock is a lock that is acquired when an item of data is read and that is held until transaction completion.
Other ways to implement optimistic locking
If you don’t have version or timestamp columns, Hibernate can still perform optimistic locking, but only for objects that are retrieved and modified in the same Session. If you need optimistic locking for detached objects, you must use a version number or timestamp.
This alternative implementation of optimistic locking checks the current database state against the unmodified values of persistent properties at the time the object was retrieved (or the last time the session was flushed). You can enable this functionality by setting the optimistic-lock attribute on the class mapping:
<class name="Comment" table="COMMENT" optimistic-lock="all">
<id ...../>
...
</class>
