Hi there,

The documentation is a little light so can someone tell me the locking
requirements for DSO. Obviously you need a "
olapLockProcess" for processing of cubes, dimensions and partitions.

But what about adding/removing/merging/cloning partitions? Do I need a
"olapLockWrite" or not.

Also, is an "olapLockRead" lock implicit or if I don't ask for one do I get
the DSO equivalent of uncommitted reads?

Finally, if I lock a cube, do I need to lock the partitions individually?

Thanks in advance,
James Snape

Hi James,

I understand that you have 3 questions in this post. Usually it is best if
we could separate them into different posts, so each post focus on only one
question.

But what about adding/removing/merging/cloning partitions? Do I need
a"olapLockWrite" or not.
olapLockWrite means that 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. Therefore, if you do not want other
applications to issue olapLockWrite at the same time and modify the object,
you need to lock with olapLockWrite.


Also, is an "olapLockRead" lock implicit or if I don't ask for one do I get
the DSO equivalent of uncommitted reads?
If you do not explicitly lock the object, not lock is applied.


Finally, if I lock a cube, do I need to lock the partitions individually?
I am performing research on this point. I will let you know if there is any
update.


Sincerely yours,

Bill Cheng
Microsoft Developer Community Support
---------------------------------------------------------------
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!
--------------------
..phx.gbl

Hi James,

According to my further research, here is the latest findings.

Whenever you write to the repository a write lock must be obtained. When
you save a major object (e.g. database, cube, partition) a temporary read
lock followed by a temporary write lock will automatically be obtained.
Otherwise read locks are not implicit and if you do not obtain one you are
basically working with last writer wins.

There is a notion of dependent object locking so that if you lock a cube
its partitions will be locked along with the data sources, the database
dimensions, and the database roles used by that cube as necessary. The
locks applied to the dependent objects depend on the lock type of the
parent object but will not always match that lock type. For example, if
you lock a cube for processing, the partitions will also be locked for
processing, but the data source will only by locked for read. If you lock
a cube for write, the partitions will be locked for write while the shared
dimensions are locked for read and the private dimensions are locked for
write and the roles and the data source are not locked at all. Locking a
database will lock all the major objects in it with the same lock type as
the database.


Sincerely yours,

Bill Cheng
Microsoft Developer Community Support
---------------------------------------------------------------
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!
--------------------
..phx.gbl