|
3.10 How to Apply Optimistic Record Locking Record locking is a restriction on viewing or editing table data usually placed on the data by a user while editing the data either to stop a conflicting picture being seen, or conflicting updates being made. Optimistic record locking takes place when one user changes some data while another user is attempting to edit it. The optimistic strategy assumes that this scenario is unlikely to happen and so does not stop either user from editing the information, but to prevent conflicts, after the data has been updated by the first person, the second will not be allowed to save any changes. The alternative (pessimistic record locking) assumes that once someone with edit privileges is viewing data, no one else should be able to access it in edit mode in case the first user wishes to edit it. The transform only supports optimistic locking. In fact the default is no record locking at all. It assumes standing data is "owned" and only those who should be updating it are (you have read the section on security, haven't you?), so whoever saves the data last is responsible for making sure it is correct and up to date. It is not always that cut and dried; in some cases more than one person is responsible for different aspects of a row. In this case it may be possible to split the table columns into two entities, for editing purposes. You may decide to update the table using code, an "update" not being sent directly to the table, but being a request to update one or more fields, handled by a business method. This is more typical of the way transaction data is handled. A third tactic is to implement optimistic record locking. To implement record locking it is necessary to have some form of row version control. This is usually a date-time or integer column, that is stamped with a unique number on row creation or update. In version 3.9 only integer is supported. This column in the transform is referred to as the version controller. It is possible to explicitly add a version controller attribute setting the versionController property on the attribute to true. However, if the entity property versionControl is set, and no versionController has been specified, one will be added. Like automatically adding an autokey, this is okay for new tables, but if you are attaching to a legacy database, you will need to model this column explicitly. Links:
Copyright © 2001-2006 New Technology / enterprise Ltd. | |||||||||||||||||||||
