This appendix describes some best practices for resource adapter developers.
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:
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.
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.
Oracle recommends that resource adapters implement the optional enhancements described in sections 7.16.1 and 7.16.2 of JSR 322: Java EE Connector Architecture 1.6. Implementing these interfaces allows WebLogic Server to provide several features that will not be available without them.
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.
Resource adapter implementations should use the
WorkManager (as described in Chapter 10, "Work Management," in JSR 322: Java EE Connector Architecture 1.6 to launch operations that need to run in a new thread, rather than creating new threads directly. This allows WebLogic Server to manage and monitor these threads.
WebLogic Server supports the Common Client Interface (CCI) for EIS access, as defined in Chapter 17, "Common Client Interface," in JSR 322: Java EE Connector Architecture 1.6. The CCI defines a standard client API for application components that enables application components and EAI frameworks to drive interactions across heterogeneous EISes.
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
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 Oracle Fusion Middleware Programming JMS for Oracle WebLogic Server.