The Next Step ‑ Excessive Contention

There will always be some contention, be it for shared physical resources such as CPU or disk, or logical constraints such as locking or queue limits. For example, housekeeping operations such as defragmentation or file archiving may be taking place on the server machine. These consume CPU and disk time resources, and as a result there are fewer of these resources available to your Jade system. If these operations take place at a time when the Jade system requires a lot of the resources (peak times, for example), they can negatively impact performance.

If your Jade system uses a shared Storage Area Network (SAN) and other machines use the SAN as well, any file operations performed by those other machines can potentially slow down the Jade system. For example, a file maintenance process running on another machine, even running under a different operating system, can slow down your database backups or online functions if they share the same SAN.

If the network is shared, someone else can slow down your network accesses by using the network for something else. For example, transferring a number of large files over the network can slow down your thin client transactions.

Locks are a fact of life in any multi‑processing environment. Locks are used to prevent simultaneous access when that access would not be valid. As a side effect, they can create logical bottlenecks. For example, if objects were not exclusively locked while in the process of being updated, one updating user could overwrite another updating user's changes. By locking the object during the update, anyone else who wants to update the object has to wait until the first update is finished. In a well‑designed system, the wait is usually very short.

One area of potential contention in Jade systems is lock time on collections. If an updater adds an object to a collection, the collection is exclusively locked until the transaction is committed. While the collection is exclusively locked, no other updater or inquirer can lock the collection. The longer an exclusive lock is held, the greater the risk of contention because of queued locks.

There are strategies to deal with this contention, as follows.

• Keep collection scope as local as possible. For example, when storing customer transactions, use a collection on the customer object rather than a global collection keyed by customer. This results in a separate collection instance per customer, which greatly reduces the likelihood of contention.

• Keep transactions short.

• Go into transaction state as late as possible.

• Update collections late in the transaction.

  Jade 2020 and higher provides support for deferring collection updates until commit time. These features can also help avoid deadlocks. For details, see "Collection Concurrency", in Chapter 4 of the Developer's Reference.

• Use an iterator or a foreach instruction with the discreteLock option, to reduce lock time on the collection.

• If a collection is frequently accessed and updated, you may be able to avoid contention by making a transient clone of the collection.

• Delay updates to collections by offloading them to another process. Note that this can introduce recovery and consistency issues, and therefore should be used only with great caution.

For more details, see the following subsections.