Troubleshooting

Troubleshooting

Cannot Map a ManagedConnectionFactory

BEA WebLogic Server writes the following message to the server log file:
Listing B-1 Cannot Map a ManagedConnectionFactory...
Cannot map a ManagedConnectionFactory to a Connection pool. Ensure that the MCF's hashcode() and equals() methods are implemented properly.
Causes and Workarounds

This exception occurs during a getConnection() method call from an application component to a resource adapter and can occur due to the following reasons:
Remote Java Virtual Machine (JVM). The application component is executing in a different JVM than the one that is hosting the resource adapter.
Improper implementation of ManagedConnectionFactory

Remote JVM

As currently specified, the J2EE Connector Architecture does not provide for remote access. None of the defined interfaces are remote, and the architected system contracts presume a local relationship between a ManagedConnectionFactory and a Connection Manager.
As a result, deploy your application so that the application components are hosted in the same Java Virtual Machine as your resource adapters.

Improper Implementation of ManagedConnectionFactory

WebLogic Server depends on the hashCode() and equals() methods of the resource adapter's ManagedConnectionFactory when WebLogic Server is managing the connections to the resource adapter. The server uses both these methods to identify a unique instance of a ManagedConnectionFactory. As a result, you need to be aware of a few things when implementing these methods in your ManagedConnectionFactory.
For a given instance of a ManagedConnectionFactory, its hashCode() method must always return the same value throughout the entire lifetime of that ManagedConnectionFactory. This begins when the associated resource adapter is deployed and ends when it is undeployed.
You must carefully write the equals() method of a ManagedConnectionFactory to distinguish between different instances of ManagedConnectionFactory. You are free to use class or instance data that can change during the lifetime of the resource adapter in the equals() method. This freedom to use modifiable data in the equals() method is new with WebLogic Server 7.0. Prior to the 7.0 release, you were restricted from doing this. BEA has changed the way WebLogic Server stores objects, such as ManagedConnectionFactory objects, in its JNDI tree.
Prior to the 7.0 release, WebLogic Server stored serialized copies of objects in the JNDI tree. For example, when a resource adapter was deployed, an entire copy of its ManagedConnectionFactory object was serialized and stored in the WebLogic Server JNDI tree. The entire state of that object at that time, including the values of all its data members, was copied and stored. Later, when a connection request was made to that resource adapter, WebLogic Server would use the ManagedConnectionFactory passed along in the connection request to try to locate the connection pool to which it had earlier assigned the deployed ManagedConnectionFactory. If the state of the ManagedConnectionFactory object had changed between deploy time and connection request time, and if this state was reflected in the behavior of the equals() method, then the two objects (the one copied into the JNDI tree at deploy time and the one presented with the connection request) were actually different objects, and WebLogic disallowed the connection request.
This is no longer a problem because WebLogic Server stores references to objects in its JNDI tree instead of copies of the objects. Now, when a resource adapter is deployed, only a reference to its ManagedConnectionFactory object is stored into JNDI. Later, when the connection request is made and WebLogic Server uses the stored reference to the deployed ManagedConnectionFactory object, it finds the same object that is now being passed along in the connection request. An invocation of the object's equals() method operates on the current state of the object, and it does not matter if the state of the object has changed since deploy time.