Using a JCO Client for Several Portal Requests 

Using a JCO Client for Several Portal Requests

When you have a pool entry instance you can get an instance of the JCO client. If you want to use a JCO client in more than one Portal request, the pool entries can be stored in static instance. When you work with static pool entries, you have to check if a HTTP session timeout has occurred. If a HTTP session timeout occurred, the JCO client service has deleted the pool entry (with method delete()) so you have to create a new connection again.

The following example stores pool entries in a static. The key in this map is defined by the user ID and session ID.

The isTimeoutOccurred() method has to called before the JCO client is used.

Example: Using a JCO client for several Portal request

public class JCOComponent extends AbstractPortalComponent
{
    private static HashMap poolEntries = new HashMap();

    public void doContent (IPortalComponentRequest request, IPortalComponentResponse response)
    {
        IJCOClientPoolEntry poolEntry
        synchronized (poolEntries)
        {
            poolEntry = (IJCOClientPoolEntry) 
                        poolEntries.get(request.getUser().getUserId()+
                            request.getServletRequest().getSession().getId());
            if (poolEntry==null || poolEntry.isTimoutOccurred())
            {
              if (poolEntry != null)
              {
                 // This code is accessed because of a timeout; inform the user, e.g.
                 response.write("The R/3 connection was terminated and will be established again: " +
                                        poolEntry.getTimeoutReason());
              }
              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;

                }
                poolEntries.put(request.getUser().getUserID()+
                    request.getServletRequest().getSession().getId(),
                                poolEntry);
            }
        }
        synchronized (poolEntry)
        {
            JCO.Client client;
            client = poolEntry.getClient();
            client.execute("myFunction"); // Example call
            // Process the results of the call
        }
    }
}

Important Issues of the Example

The access to the static map that holds all pool entries is synchronized.

We do not known how many threads execute the doContent() method at a time. Even the same user can execute the method within different threads. Therefore the table must be kept in a consistent state.

The Portal Runtime (PRT) can release Portal components when memory is needed.

Consider this if using statefulcomponents. The PRT calls the Portal component method destroy() to release a component. This method can be used also to manage the open connections, for example, to release stored pool entries.

The execution of the client call is synchronized.

JCO clients are not thread safe and when the same user enters doContent() from several threads, the access to his client must be synchronized.

Pool entries are not released.

Pool entries are released by the JCO client service when a HTTP session timeout occurs or by the Java VM finalizer. The method finalize() of the class JCOClientPoolEntry calls the release() method itself. This will take place when iView is not referenced by the PRT anymore, because it was released from the PRT or the Portal was shut down. The garbage collector finalizes the whole iView including the hash map.

When a HTTP session timeout occurs the delete() method is called - so the JCO client is only disconnected; in case of finalize the release() method is called - so the JCO client is disconnected and is returned to the pool.