When preparing resource adapter classes for packaging in a RAR file, consider Oracle’s best practices for classloading optimizations.

You can package resource adapter classes in one or more JAR files, and then place the JAR files in the RAR file. These are called nested JARs. When you nest JAR files in the RAR file, and classes need to be loaded by the classloader, the JARs within the RAR file must be opened and closed and iterated through for each class that must be loaded.

If there are very few JARs in the RAR file and if the JARs are relatively small in size, there will be no significant performance impact. On the other hand, if there are many JARs and the JARs are large in size, the performance impact can be great.

To avoid such performance issues, you can do either of the following:

1. Deploy the resource adapter in an exploded format. This eliminates the nesting of JARs and hence reduces the performance hit involved in looking for classes.

2. If deploying the resource adapter in exploded format is not an option, the JARs can be exploded within the RAR file. This also eliminates the nesting of JARs and thus improves the performance of classloading significantly.

Lazy Connection Association Optimization, as described in section 7.16.1, allows the server to automatically clean up unused connections and prevent applications from hogging resources. Lazy Transaction Enlistment Optimization, as described in 7.16.2, allows applications to start a transaction after a connection is already opened.

As a best practice, you should not store the InteractionSpec class that the CCI resource adapter is required to implement in the RAR file. Instead, you should package it in a separate JAR file outside of the RAR file, so that the client can access it without having to put the InteractionSpec interface class in the generic CLASSPATH.

With respect to the InteractionSpec interface, it is important to note that when all application components (EJBs, resource adapters, Web applications) are packaged in an EAR file, all common classes can be placed in the APP-INF/lib directory. This is the easiest possible scenario.

This is not the case for standalone resource adapters (packaged as RAR files). If the interface is serializable (as is the case with InteractionSpec), then both the client and the resource adapter need access to the InteractionSpec interface as well as the implementation classes. However, if the interface extends java.io.Remote, then the client only needs access to the interface class.

When using an EJB or servlet to send messages using a JCA adapter backing a JMS provider using XA transactions, the resource-ref needs to be java.lang.object.

In a WebLogic Server environment, specifying javax.jms.ConnectionFactory implements WebLogic JMS Wrappers which are not compatible with this JCA adapter configuration. See Enhanced Support for Using WebLogic JMS with EJBs and Servlets in Developing JMS Applications for Oracle WebLogic Server.