APPENDIX A n MORE ADVANCED FEATURES 237 n MORE ADVANCED FEATURES 237 environment, it is not unlikely that Client A will close a browser window on the open record, never committing or canceling the transaction, so that the record remains locked until the session times out. Clearly this is not a satisfactory solution. Usually, you will not want to permit the alternative scenario, in which no locking is used, and the last person to save a record wins! The solution, versioning, is essentially a type of optimistic locking (see Chapter 
. When any changes to an entity are stored, a version column is updated to reflect the fact that the entity has changed. When a subsequent user tries to commit changes to the same entity, the original version number will be compared against the current value if they differ, the commit will be rejected. The Hibernate/EJB 3 annotation mappings and the Hibernate XML-based mappings both provide a simple syntax for indicating which field should be used for storing the managed version information. The annotation for this field is shown in Listing A-5. Listing A-5. Marking the Version Attribute Using Annotations @Version protected int getVersionNum() { return versionNum; } The default optimistic locking strategy for Hibernate is versioning, so if you provide a element in your XML configuration, this will be used as long as you have enabled dynamic updates (as shown in Listing A-6). Listing A-6. Marking the Version Attribute Using XML Mappings … The version attribute is defined in a very similar way to the normal property attribute configuration. The version can be of type long, integer, short, timestamp, or calendar (note that using the element is an equivalent alternative to the use of the element syntax). The element s optimistic-lock attribute can be used to override the default versioning-based optimistic locking strategy. You can disable it entirely (despite the presence of a version field) using a value of none. You can explicitly state that versioning should be used with a value of version. You can elect to use dirty checking, with the dirty and all options. If you elect not to use versioning, dirty checking offers an alternative form of optimistic locking. Here, the values of the entities are themselves checked to see if they have changed since the entity was originally obtained. As with versioning-based optimistic locking, the check against the database is carried out when the changes are committed. If an optimistic lock type of dirty is selected, then only those fields that have changed since the persistent entity was obtained will be checked (the Session keeps track of the appropriate state information). If an optimistic lock type of all is selected, then all the fields comprising the entity will
You need excellent and relaible webhost company to host your web applications? Then pay a visit to Inexpensive Web Hosting services.
This entry was posted
on Wednesday, August 8th, 2007 at 5:10 pm and is filed under tomcat.
You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.