Object Locking with Decision Support Objects
Note
This feature will be removed in the next version of Microsoft SQL Server. Do not use this feature in new development work, and modify applications that currently use this feature as soon as possible.
If you are developing applications for use in a multiple-administrator environment, you should become familiar with the LockObject and UnlockObject methods. These methods provide for repository stability when changes are made to Microsoft® SQL Server™ 2005 Analysis Services objects. When one application obtains a lock on an object, the options available to other applications are restricted until the lock is released. The use of object locking can provide performance benefits when working with Decision Support Objects (DSO) objects, and it can forestall some errors in multiple user object access situations.
When an application disconnects from the server, all locks it left in place are automatically released. This prevents objects from being locked indefinitely from unexpected circumstances.
The types of locks defined by the OlapLockTypes enumeration are: olapLockExtendedRead, olapLockProcess, olapLockRead, and olapLockWrite.
olapLockExtendedRead
The object's properties can be read by other applications, but cannot be changed or processed. This lock is used to prevent processing of dependent objects of an object that is being processed, such as dimensions that are shared by multiple cubes. Multiple olapLockExtendedRead locks may be applied to an object by multiple applications. However, no application can lock the object for processing or writing until all olapLockExtendedRead locks have been released.olapLockProcess
The object's Process method can be called and other applications can read the object's properties only until the lock is released. Only one olapLockProcess lock can be applied to an object at a time, and other applications can apply olapLockRead locks only while the olapLockProcess lock is in place.olapLockRead
The properties of the object can be read from the repository and cannot be changed by another application until the lock is released. Other applications can issue olapLockRead, olapLockExtendedRead, and olapLockProcess locks, but not olapLockWrite locks, while the initial olapLockRead lock is in place.olapLockWrite
The properties of the object can be modified in the repository using the Update method, and are not available to other applications for any use until the lock is released. No other locks of any type can be applied to the object by another DSO client until the olapLockWrite lock is released.
The different lock types are not valid for all objects that have a LockObject method. Review the different method descriptions for information about the lock types each object supports.
It is sometimes possible for an application to obtain an additional lock on an already locked object. The following table defines what lock options are available to an application (App2) that wants to request a lock on an object that is currently locked by another application (App1).
|
App2 can obtain lock |
|
|
|
|---|---|---|---|---|
App1 lock obtained |
olapLockRead |
olapLock ExtendedRead |
olapLockProcess |
olapLockWrite |
olapLockRead |
Yes |
Yes |
Yes |
No |
olapLock ExtendedRead |
Yes |
Yes |
No |
No |
olapLockProcess |
Yes |
No |
No |
No |
olapLockWrite |
No |
No |
No |
No |
If a lock request is denied, DSO raises the error mderrLockCannotBeObtained. If the lock request was denied because the object is already locked by another application, the Description property of the Error object contains the name of the user holding the lock, the computer name where the lock was obtained, and the description the application provided when it obtained the lock.
In certain situations, an application can delete an object and cause another application to fail if both applications are using the same object. For example, assume that App1 creates an object and obtains an olapLockWrite lock, and App2 obtains an olapLockRead lock on the same object. If App1 deletes the object, the object reference in App2 will now not be valid. You can check the validity of an object in this situation by examining its Parent property, which does not contain a valid parent object if the object reference is not valid.
See Also