Best practice when writing a Multi-threaded application using the Information Integrator for Content (II4C) API.

Content

Multi-threaded application development:

In an application, it may be that a single user's session spawns multiple threads. If these threads are sharing a connection instance, then care must be taken to ensure that multiple threads are not using the connection object, or any of the objects associated with the connection, at the same time. This can be accomplished by using synchronization to ensure that each thread is the only thread actively using the connection. This caution is needed for applications developed with the Java Beans or using the DK APIs.

If you are using the Java beans when developing your application, there are some special cautions about synchronization in your application.

Java beans methods that make calls to the server use internal synchronization on the CMBConnection object. Each thread must synchronize objects in the same order to avoid introducing deadlocks.


All of the java beans methods that make server calls contain internal or external synchronization on the CMBConnection object. Any custom application synchronization would have to be completed in the same order on each thread before calling any of these methods and invoking the internal synchronization on CMBConnection.

Many CMBConnection methods are externally synchronized, and there are also methods with internal synchronization on the CMBConnection instance:

CMBConnection.getSchemaManagement()
CMBConnection.getAuthorizationManagement()
CMBConnection.getDataManagement()
CMBConnection.getQueryService()
CMBConnection.getDocRoutingDataManagementICM()
CMBConnection.getDocRoutingQueryServiceICM()
CMBConnection.getWorkFlowDataManagement()
CMBConnection.getUserManagement()

For CMBDataManagement, CMBSchemaManagement, CMBQueryService, and CMBAuthorizationManagement, all methods that require calls to the server to update or retrieve data, or to execute a query, are internally synchronized on the CMBConnection bean.


Native connectors:
When using the datastore connector APIs, all calls to datastore instances for a specific server type may be routed to the same native DLL for processing. The more threads there are on a single application server, the more likely you are to experience a performance hit due to all of the threads having to share time. This can cause a performance bottleneck, and you must engage in load testing for the expected peak usage of your application to ensure your servers can handle the load.