| PATH |
A single database column that contains locking state information can be useful in certain situations. Sometimes an object must be locked for a long period. Optimistic or pessimistic locking won't work in this case because when an application saves or reverts an object, the object is released. For these cases you should add a column whose value changes when the object is locked.
Locking on a column is normally used with optimistic or pessimistic locking to ensure that only one user can update the locking column. For example, if you are using optimistic locking, the locking column should be selected as a locking attribute in EOModeler. This step ensures that when the user tries to save the object no one else has already locked it.
Setting the lock on the column can be somewhat tricky. To lock the object you should create a separate EOEditingContext and use that context to update the record for the lock object. An separate editing context is needed because if other objects have been modified in the main EOEditingContext they would also be saved along with the lock object. A simple way to lock and unlock objects is to add the following two methods to your enterprise objects and only invoke them before any modifications are made to the object.
- (void)lock { EOEditingContext *aContext; id lockingObject; aContext = [[EOEditingContext alloc] init]; lockingObject = [aContext faultForGlobalId:[[self editingContext] globalIDForObject:self] editingContext:aContext]; [lockingObject setLock:@"Y"]; [aContext saveChanges]; [aContext release]; } - (void)unlock { EOEditingContext *aContext; id lockingObject; aContext = [[EOEditingContext alloc] init]; lockingObject = [aContext faultForGlobalId:[[self editingContext] globalIDForObject:self] editingContext:aContext]; [lockingObject setLock:@"N"]; [aContext saveChanges]; [aContext release]; }
The simplest way to lock an object is to use a simple Boolean column. This can be a single bit (0 or 1) or a single char (Y or N). This approach preserves table space but gives you no way to know who locked the record or when they locked it.
You can also create a date column that is set to the current date when the object is lock and to NULL when the object is not locked. This technique enables you to determine when the object was locked. It can enable you to implement automatic lock removal after a specific period has elapsed. This technique, however, takes up more table space than a Boolean and it does not give you a way to determine who locked the record.
You can also set the locked column to be the user name or user ID of the user who locked the column (NULL otherwise). This approach allows you to determine who locked the object. It also gives you a way to allow them access to this object across different instances of an application. However, this approach also takes up more table space than a Boolean and it gives you no way to know when the record was locked.
You can combine two columns for locking, one to store the user ID (or name) and the other to store the date. This technique combines the strengths of the two approaches described earlier (" Using a Date in the Locked Column " and " Using a User Identifier "). However, it requires more table space than all the other options.
22 July, 1998. Paul Haddad. First Draft.
18 November, 1998. Terry Donoghue. Second Draft.