Some external software that directly impact your applications
can limit container-managed persistence (CMP) features. However, you
can work around these limitations.
In each case, only very specific behaviors of the software place
restrictions on your CMP beans. The following tips help you prevent
these behaviors.
CMP deployment and Sybase IMAGE type restriction
When
deploying enterprise beans with container managed persistence (CMP)
types that are non-primitive and do not have a natural JDBC mapping,
the deployment tool maps the CMP type to a binary type in the database,
where it is stored as a serialized instance. For Sybase, the tool
uses the JDBC type LONG VARBINARY. The Sybase driver maps LONG
VARBINARY to the native type IMAGE.
Although the
type VARBINARY has fewer restrictions than IMAGE in
Sybase, you cannot use it because it is limited to a size of 255 bytes,
which is too small for typical serialized Java objects.
The
specific restrictions on the IMAGE type are:
- You cannot use the IMAGE type in the WHERE clause
of an SQL query. You can encounter this restriction whenever an enterprise
bean contains an EJB-QL query that has a CMP type in the WHERE clause,
which maps to the IMAGE type in the Sybase relational database.
- You cannot use IMAGE type in select queries marked DISTINCT.
This situation arises in these user scenarios:
- When the DISTINCT key word is specified in an EJB-QL select
query having a Java type mapping to IMAGE.
- When Enterprise beans have finder and ejbSelect() methods returning
java.util. Set and have CMP types mapping to IMAGE.
To work around this restriction, edit the EJB mappings
in the Rational® Application Developer toolset and
do either of the following:
- If you are sure that the serialized instance of the CMP
type is never larger than 255 bytes, you can change the CMP
type mapping from IMAGE or LONG VARBINARY to VARBINARY.
- Map the CMP type to multiple RDB fields through a composer. For
example, if the CMP type is a Java object
X with an int field and a string field, then map X to two RDB fields INTEGER and VARCHAR,
using a composer. Refer to the Rational Application
Developer documentation for more information about using composers.
A ClassCastException exception occurs when running
CMP 1.1 beans
If you created your Enterprise JavaBeans (EJB) application using Rational Application
Developer or WebSphere® Studio Application Developer
Integration Edition, Version 4.0.x , and the application contains
container managed persistence (CMP) 1.1 beans with associations (relationships),
you might receive a
java.lang.ClassCastException exception
when you run your application on WebSphere Application
Server.
Deprecated feature: Business processes modeled with WebSphere
Studio Application Developer Integration Edition Version 5.0 or earlier
are deprecated.
depfeat
The cast operation generated by Rational Application
Developer or WebSphere Studio Application Developer
Integration Edition, Version 4.0.x, does not use the javax.rmi.PortableRemoteObject.narrow(...) object
to convert the remote object to the remote interface of CMP beans
in the XToYLink.java (or YToXLink.java) class where
X and Y are CMP 1.1 beans.
Recommended response:
- Locate the following methods in all link classes, for example,
XToYLink.java and YToXLink.java where X and Y are CMP 1.1 beans:
public void secondaryAddElementCounterLinkOf(javax.ejb.EJBObject anEJB)
public void secondaryRemoveElementCounterLinkOf(javax.ejb.EJBObject anEJB)
public void secondarySetCounterLinkOf(javax.ejb.EJBObject anEJB)
- Add the javax.rmi.PortableRemoteObject.narrow(...) object to convert
the remote object to the remote interface of CMP beans.
For example, change the following original method:
public void secondaryAddElementCounterLinkOf(javax.ejb.EJBObject anEJB) throws java.rmi.RemoteException {
if (anEJB != null)
((X) anEJB).secondaryAddY((Y) getEntityContext().getEJBObject());
to:
public void secondaryAddElementCounterLinkOf(javax.ejb.EJBObject anEJB) throws java.rmi.RemoteException {
if (anEJB != null)
((X) anEJB).secondaryAddY((Y)
javax.rmi.PortableRemoteObject.narrow(getEntityContext().getEJBObject(), Y.class));