This article provides troubleshooting information for EJBDEPLOY problems.
The EJB 3.0 specification
introduces Just-In-Time (JIT) deployment where the EJB container dynamically
generates the wrapper, stub, and tie code in-memory as needed when
the application is running. This means that if you are using the EJB
3.0 modules, you do not need to process your EJB 3.0 modules through
the EJBDeploy tool prior to running them in WebSphere Application
Server.
DSNT408I SQLCODE = -613, ERROR: THE PRIMARY KEY OR A UNIQUE CONSTRAINT IS TOO LONG OR HAS TOO MANY COLUMNS DSNT418I SQLSTATE = 54008 SQLSTATE RETURN CODEThis problem can be seen when the primary keys that are created for the two related beans have primary keys that are strings. This results in the composite being made up of 2 varchar(250) primary keys for a total of 500, which is greater than 254 maximum in DB2 for z/OS version 7.x.
EJBDEPLOY_JVM_ARGS
Set
the EJBDEPLOY_JVM_ARGS property to override Java virtual
machine (JVM) options that are passed to the code that deploys EJBs
(ejbdeploy.sh). Set this property in one of the following locations: deploymentmanager/bin/setupCmdLine.sh
or appServerHome/bin/setupCmdLine.sh
export EJBDEPLOY_JVM_ARGS="-DEJBDEPLOY_GENERATE_UNQUALIFIED_SQL=true"
The mapping for primary key fields to database columns may use a converter to transform the key values. If a container-managed persistence (CMP) bean uses a converter to map its primary key, and that bean has a relationship where the bean at the other end holds a foreign key, the mapping for the foreign key will not use the converter.
No type mapping defined for Java datatype1 to Database datatype2During run time, the application does not find the CMP bean at the other end of the relationship.
To work around this limitation, define your own foreign key in the database table, and create a mapping that uses the same converter as defined for the primary key on the enterprise beans at the other end of its relationship.