Container interoperability
Container interoperability describes the ability of WebSphere Application Server clients and servers at different versions to successfully negotiate differences in native EJB finder methods support and J2EE compliance.
Interoperability of the handle formats in WebSphere Application Server, V5 and V5.0.1
Applications that attempt to persist handles to enterprise beans and EJBHome needed to subclass ObjectInputStream in WAS, V5. This action was required so that the subclass ObjectInputStream could utilize the context class loader to resolve the classes for enterprise beans and EJBHome stubs.
In addition, handles created and persisted in WebSphere Application Server, V5 only work with objects that have an unchanged remote interface. If the remote interface is changed, the handle is no longer valid because the stub is serialized inside the handle and its serial VUID changes if the remote interface changes.
This release introduces a new handle persistence mechanism that avoids the implementation drawbacks of the previous version. However, if handles are used for this WAS deployment, you should consider the following issues when applying this update, future WAS Fix Packs and EJB Container cumulative fixes for WAS, V5.
If a WebSphere Application Server, V5 persisted handle or home handle is encountered by a WebSphere Application Server, V5.0.1 system, it can be read and utilized. In addition, it will be converted to WAS, V5.0.1 format if it is re-persisted. The WAS, V5.0.1 format cannot be read by a WAS, V5 system unless PQ72184 is applied.
Problems arise when handles are persisted and shared across systems that are not at the WAS, V5.0.1 level or later. However, a V5 system can receive a handle from V5.0.1 remotely through a call to get a handle on an enterprise bean or a getHomeHandle on an EJBHome. The remote call will succeed, however, any attempt to persist it on the V5 system will have the same limitations regarding the use of ObjectInputStream and changes in remote interface invalidating the persisted handle.
When your application stores handles persistently and shares this persistence with multiple clients or appservers, apply WAS, V5.0.1 or PQ72184 to both the client and server systems at the same time. Failure to do so can result in the inability of these systems to read the handle data stored by upgraded systems. Also, handles stored by the WAS, Version 5 can force the applications of the updated system to still subclass ObjectInputStream. Applications using the WAS Enterprise, V5 scheduler and process choreographer, are affected by these changes. These users should update their V5 systems at the same time with either Version 5.0.1 or PQ72184.
If the applications store handles in the session context, or locally in a file on the same system, that is not shared by other applications, on different systems, they might be able to update their systems individually, rather than all at once. If Client Container and thin client applications do not share persisted handle data, they can be updated as needed as well. However, handles created and persisted in WAS, Version 5, V4.0.3 and later (with the property flag set), or V3.5.7 and later (with the property flag set) are not usable if either the home or the remote interface changes.
If any WAS, Version 3.5.7 or V4.0.3 and later enables the system property com.ibm.websphere.container.portable to true, any handles to objects on that server have the same interoperability limitations. In addition, if any WAS, V3.5.7 and later or V4.0.3 applications store a handle obtained from a WebSphere Application Server, V5 or V5.0.1, the same restrictions apply, regarding the need to subclass ObjectInputStream and the usability of handles after a change to the remote interface is made.
Replication of the Http Session and Handles
This note applies to you if you place Handles to Homes or Enterprise JavaBeans, or EJB or EJBHome references in the Http Session in your application and you use Http Session Replication. If you intend to replicate a mixed environment of V5.0.0 and Version 5.0.1 or 5.0.2 machines you should first apply the latest V5.0.0 container cumulative e-fix to the V5.0.0 machines before allowing the Version 5.0.1 or 5.0.2 server into the typology. The reason for this is that Version 5.0.0 servers are not able to understand the persisted Handle format used on the V5.0.1 and 5.0.2 server. This is similar to the case of Version 5.0.0 and V5.0.1 or 5.0.2 systems trying to use a shared database, mentioned above. But in this case, it is the Http Session object and not the database providing the persistence.
Top Down Deployment Mapping
The size of the Handle objects has grown due to the fix put in to allow serialization and deserialization to occur without the previous requirements of subclassing the ObjectInputStream and so on. Top down deployment of an object that contains EJB and EJBHome references create a database table ddl that has a field of 1000 bytes of VARCHAR for BITDATA which will contain the Handle. It might be that your object's Handle does not fit in the 1000 byte default field, and you might need to adjust this to a higher value. You might try increments of 250 bytes, that is, 1250, 1500, and so on.
Related concepts
EJB containers
Related tasks
Manage EJB containers
Related Reference
EJB container settings
Reference topic