Child pages
  • Instance Locking
Skip to end of metadata
Go to start of metadata

Component Instance Locking is used to synchronize concurrent method executions on an instance. The locking takes place for all executions on the instances managed by a single server instance. It is inherently built into all executions and ensures that a single instance may only be locked by one method at a time, thus serializing access to the instance.

Component Instance Locking and Host Locking are always both active and prevent deadlocks when interacting with instances and hosts respectively.

Isolation levels

This section describes the different isolation levels (and terms) used for locking method executions. In contrast to Host Locking the developer cannot influence the isolation levels of instance locking, but is determined automatically.

Exclusive Locking

Exclusive Locking is used when creating, updating, and deleting instances.

With exclusive locking an instance will be locked, such that no other execution can take place for the duration of the locking method. This means that any other method trying to access the instance in question will be blocked, until it is unlocked again, regardless of the isolation level.

Shared Locking

Shared Locking is used when calling control methods on instances.

Shared locking allows other executions to take place at the same time for the instance in question, if and only if these are shared lock executions as well. In other words, exclusively locked instances cannot be accessed by a shared method at the same time.

Technically, the locking key consists of the fully qualified name of the component instance in which the model version has been removed, e.g. component(myhost):/examples/MyComponent@{myidentifier}). The model version is not relevant because the same component of different version cannot be installed on the same host with the same component instance identifier.


With multiple method executions in parallel, it may well happen, that two or more executions are trying to lock different instances interdependently, i.e. two methods each owning a lock on instance A and B trying to lock the other instance, respectively. This so-called deadlock situation will be detected by the system prior to acquiring the instance lock in question, so that no two executions end up waiting for each other. In fact, the latter of the two executions will be aborted, thus preventing the deadlock situation detected.

A deadlock can also occur by the combination of Host Locking and Instance Locking, e.g. if one method has a host lock A and tries to lock an instance B and another method holds the lock of instance B and tries to lock the host A. This also will be detected and the executions will be aborted.

It is the obligation of the automaIT developer or architect to avoid deadlocks in the first place, e.g. by designing the plans and components using well-defined strategies. Deadlocks actually prevented by the system should always be avoided by well designed code.

  • No labels