At 09:56 AM 4/30/96 -0700, Thomas Harmon wrote: >Is there any way to get around Images requirement of have the whole dataset >locked when doing a DBPUT or DBDELETE? Our locking strategy is to only lock >those particular entries that are capable of being changed which is easy with >a MODE=6 and a lock list. Our problem is if any user has some entries locked >for change mode, no other users can lock the whole dataset in order to do an >add or delete. Surely there must be a solution other than not having entries >locked during "think" time? IMAGE's locking facility provides a 'logical' lock to a database in order to protect the logical integrity of the shared data. There is no requirement that one 'logically lock' an entire dataset to perform a DBPUT or DBDELETE. It is perfectly acceptable to place a logical lock on an item value which does not exist as a pre-cursor to performing a DBPUT or an item value being removed via DBDELETE. The key point is that the applications that share the data involved adhere to a locking strategy which protects the integrity of the data while maximizing throughput associated with concurrent access. Internally, IMAGE has a mechanism it utilizes on DBPUT/DBDELETE to single-thread these activities in order to protect the internal structures of the database itself. For example, suppose an application performs a DBPUT to a detail dataset with a single logical lock on the primary search path. However, this dataset has several other masters associated with it and the chains in these masters (or new master entries in the case of auto-masters) have to be updated to reflect the new entry. The same is true with DBDELETEs. IMAGE utilizes its internal mechanism to single-thread PUTs/DELETEs in order to protect the structural aspects of all datasets involved. This DBPUT/DBDELETE single-threading mechanism for IMAGE structural intregity has become a growing issue, particularly on the high-end systems. HP is working on improvements to this process so as to provide for more concurrent throughput while continuing to protect the structural intregity of the database. It should also be pointed out that it is not required that a search field be the data item utilized for the logical lock. It is perfectly acceptable to conduct locking on a non-search item. The key point to remember is that all accessors have to utilize an agreed upon locking strategy. Also, case must be used in developing a locking strategy. Otherwise it is easy to get into dead-lock situations.... :) -- Jerry =================================================== Democrary is a process by which the people are free to choose the person who will get the blame. -- Lawrence J. Peter ===================================================