Recommendations for JCO Clients 

For a good performance and resource management it is important that JCO clients are released properly.

When a JCO client is no longer needed, it should be returned to the pool by calling the release() method. If you want to make sure that the JCO client is no longer used, you should disconnect the JCO client by calling the delete() method.

The JCO client service keeps track of the pool entries and the connection limit. If the limit is exceeded the JCO client service prevents that new calls of the getJCOClientPoolEntry() method get a pool entry.

Never release a JCO clientwhen it is still used or referenced. This JCO client would be available then for other threads. This would cause system errors because a JCO client may not be used in different threads at the same time.

The connection limit involves connections from the time the pool entry was obtained (using the getJCOClientPoolEntry() method) until it is released or deleted by the application or by the JCO client service (in case of HTTP session timeout) or the Java VM finalizer. What you do with the connection while it is established does not affect the connection limit.

The Java VM finalizer calls the release() method when a JCO client is no longer referenced. If you do not release the JCO clientwith the release() or delete() method, it is active until a HTTP session timeout occurs or the Java VM finalizer releases it. If the JCO client is referenced and the iView is being used, the Java VM finalizer might not be able to remove the JCO client the application has to release or delete the JCO client. See chapter Using a JCO Client for Several Portal Requests for more details.

When the release() or delete() method was already called by the application, the Java VM finalizer does not call the release() method again.

Special attention must be paid to pool entries that are used for several Portal requests. The application must implement a proper synchronization that one JCO client is not used by different threads. See the example in chapter Using a JCO Client for Several Portal Requests for more details

When you want a JCO client to work with a JCO repository, the pool entry must not be released while the repository is still accessed.

Example: Create a JCO repository directly

public class JCOComponent extends AbstractPortalComponent 
{ 
     private static JCO.Repository repository = null; 
     private static IJCOClientPoolEntry poolEntry = null; 
     public void doContent (IPortalComponentRequest request, IPortalComponentResponse response) 
     { 
                if (repository==null || poolEntry.isTimeoutOccurred()) 
                { 
  // either the repository is not yet there or there was a timeout; get a new client and a new repository 
        IJCOClientService clientService = 
                     (IJCOClientService)request.getService(IJCOClientService.KEY); 
        try 
        { 
          poolEntry = clientService.getJCOClientPoolEntry("SAP_PLM", request); 
        } 
        catch / 
        { 
            response.write("Currently no connection available. Please try again.");
            return;        } 
        repository = new JCO.Repository("PLM_DMS1", poolEntry.getClient()); 
        // important: keep the pool entry, i.e. do not call release 
      } 
    // use the repository 
  } 
}

In this example all users that execute the iView use the same repository. The pool entry is not released in this example because the previous pool entry has been deleted by the JCO client service as a result of a HTTP session timeout.

The isTimeoutOccurred() method is called before the repository is used (except the creation of the repositories).