Programming Guides › Programming Guide for Java Connector Server › Updating Endpoint Objects › How Connectors Avoid Race Conditions

How Connectors Avoid Race Conditions

You can use forceModificationMode=REPLACE to normalize all requests to REPLACE requests only. This is valuable for connectors and endpoints that can accept only REPLACE requests, including the SAP connector. For more information about this setting, see Updating an Object.

Identity Manager splits DELTA requests mentioning multiple objects into multiple separate requests, to allow for different workflows for each change. However, this splitting can cause race conditions in which DELTA requests can end up overwriting each other.

To avoid this problem, when the JCS receives multiple requests targeting the same object, it locks those requests to permit only one request being processed at a time. Each lock is keyed to the connector-speak Distinguished Name of the target object. The JCS maintains these locks in a cache.

However, this locking works only for connectors within a single JCS instance. If you have multiple JCS instances running, and connectors from each instance are targeting the same endpoint, you might see problems due to race conditions.

Note: CA Identity Manager uses DELTA and splits, for communications between its internal components. The forceModificationMode setting affects requests only when they are sent from the connector to the endpoint.

Example: Add roles to an SAP account

The SAP connector can accept REPLACE requests only, so this connector uses forceModificationMode=REPLACE.

1. An administrator uses the User Console to add fifteen roles to an existing SAP account.
2. CA Identity Manager splits the request into fifteen separate add delta requests (one for each role being added) targeted at the same account. This allows each request to have a different workflow.
3. Because many requests are going to be sent which target one object, the Java CS locks them, ensuring that each request will be sent only when the previous one has been processed.
4. To convert the MODIFY requests into REPLACE requests, Java CS does the following for each request:
   1. It asks the SAP endpoint for the account's existing roles.
   2. It creates a new request that adds one role to the existing roles.
   3. It sends the REPLACE request.
5. When all requests for the account have been processed, the lock is released.

This ensures that each request is fully processed before the next is sent. If these fifteen requests were sent at the same time without locking, some would probably overwrite others, leading to some roles not being added to the account.

Avoid Race Conditions in Custom Connectors

If you are writing or modifying your own connectors and you need to avoid race conditions, you can use the same cache of locks.

To use it, call the MetaConnector.getModifyMonitorCache() method. The key is the connector-speak DN of the target object. You can then use normal Java synchronize calls on the object returned from the cache to lock.