11.07.2015 Views

Caché ObjectScript Reference - InterSystems Documentation

Caché ObjectScript Reference - InterSystems Documentation

Caché ObjectScript Reference - InterSystems Documentation

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

<strong>Caché</strong> <strong>ObjectScript</strong> Commands• ^c is unlocked and removed from the lock table. ^c had a shared lock count of 1.• ^d is unaffected. The unlock attempted to unlock an exclusive lock, but ^d did not havean exclusive lock; it had (and continues to have) a shared lock count of 1.• ^e has both an Exclusive and a Shared lock. The unlock removed the Exclusive lock, butleft the shared lock with a lock count of 1.If a specified lock name does not have any locks on it, no operation is performed.Locking ProtocolBy itself a lock does not prevent another process from modifying the associated data because<strong>Caché</strong> does not enforce unilateral locking. Locking works only by convention: it requiresthat mutually competing processes all implement locking on the same variables.All processes in competition for write access to a given variable must lock that variable priorto updating it. A lock remains in effect until it is unlocked by the process that set it. Thus,each process must unlock the variables when it finishes with them. Without this cooperation,the concept of locking has no meaning.While in effect on a given variable, a lock causes a wait condition for any other process thatattempts to lock that variable. If a process simply writes to a locked variable without firstasserting its own lock, the write attempt will succeed.<strong>Caché</strong> maintains a system-wide lock table that records all locks that are in effect and theprocesses that have set them. Use the System Management Portal or the LOCKTAB utilityto display the existing locks in the Lock Table or to remove selected locks.Locks on Local VariablesThe behavior of LOCK on local (non-careted) variables is the same on <strong>Caché</strong>, Open M[DTM], and DSM for OpenVMS. Refer to $ZUTIL(69,8) Set ZA and ZD Modes for informationon compatibility with older DSM for OpenVMS locking commands.In Open M [DTM] and DSM for OpenVMS, local locks are always taken out in the manager'sdataset regardless of the first character. If an application ported to <strong>Caché</strong> uses local locks thatdo not begin with a % character, the application may experience deadlock conditions if ituses the same, local, non-% lock names in different datasets. The locks now collide becausethey resolve to the same item. If this is part of a hierarchical locking system, a deadly embracemay occur that can hang an application.The current behavior is:• Local (non-careted) locks acquired in the context of a specific namespace, either becausethe default namespace is an explicit namespace or through an explicit reference to a86 <strong>Caché</strong> <strong>ObjectScript</strong> <strong>Reference</strong>

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!