This topic outlines current, known limitations and restrictions
for EJB deployment.
Running older versions of code generation tools
This
limitation is applicable to applications that uses WebSphere® extensions and bindings. However,
if your application does not use any of the WebSphere extensions and bindings; and
only implements code from the J2EE specifications, than this limitation
is not applicable. Hereafter in this limitation, the term "application"
defines an enterprise application that uses WebSphere extensions and bindings.
When
an application is coming from a newer version of the product, you
cannot run code generation tools from an older version of the application
server. For example, if an EJB application is developed in version
8.0 of the development workbench, you cannot run ejbDeploy command
from WebSphere Application
Server v6.1.
The application developed in the newer version
of the products include additional functions or fixes that are not
recognized in older code generation tools.
Instead, use the
code generation tools from the newer version of the product to package
the application as a deployable enterprise artifact (EAR) file. The
newer version of the development products provides binary compatibility
support to older runtime servers as long as the server supports the
J2EE specification level and technology used in the application.
Running the ejbDeploy command can generate compilation
errors for DB2 V9 for z/OS
If
you have an enterprise bean (EJB) JAR file that contains mappings
to a DB2® V9 z/OS® back end (DB2UDBOS390_V9) along with back
ends from other database vendors and these back ends have mappings
to a collision detection column (OCC column), you might get compilation
errors when generating deployment code for the enterprise bean. See
Running the ejbDeploy command may
generate compilation errors for DB2 V9
for z/OS topic for details.
EJB mapping limitations and restrictions
- SQL Server mapping problem with FLOAT data type: If your CMP bean
has been mapped to an SQL Server database, then a field of type float
needs to be mapped to a column of type FLOAT, not REAL.
- Support for mapping enterprise beans to foreign keys and primary
keys: When you are mapping an enterprise bean to a database table,
there are several restrictions involving foreign keys and primary
keys:
- If the table has multiple foreign keys that contain multiple columns,
the foreign keys cannot overlap each other if both foreign keys are
used in a mapping to two different EJB relationships. For example,
if ForeignKey1 contains ColumnA and ColumnB, ForeignKey2 can contain
ColumnC and ColumnD, but cannot contain ColumnB and ColumnC. If ForeignKey2
contains ColumnB and ColumnC, the two foreign keys would overlap each
other.
- If the table has a multi-column primary key and one or more foreign
keys that share those columns, the foreign keys must either contain
the same columns as the primary key or contain columns entirely outside
the primary key. For example, if PrimaryKey1 contains ColumnA and
ColumnB, ForeignKey1 can contain ColumnA and ColumnB or ColumnC and
ColumnD, but it cannot contain ColumnB and ColumnC. For multiple foreign
keys, each foreign key must meet this requirement.
- If you have a foreign key to two different tables, you cannot
use the EJB mapping tools to map more than a single one-to-many (1:M)
relationship from beans to a single foreign key of another bean. The
foreign key needs to be unique to each relationship.
- Inheritance and secondary table mapping: If you are using the
root-leaf approach to mapping inheritance or are using secondary maps
with multiple tables, you should remove the foreign-key constraints
from the database to avoid referential integrity ordering issues (SQL
statements executed out of order).
- The EJB to relational
database mapping tools does not support tables with unique constraints.
For details to work around mapping tables with unique constraints,
see the Problems mapping EJB Beans
from relational tables with unique constraints topic.
- The EJB to relational database mapping tools
do not support mapping to materialized view or materialize query table.
A definition of materialized view or materialized query
table is based on the result of a query and whose data is in the
form of previously computed results that are taken from table or tables.
Data can be accessed from the materialized view or table instead
of the data from the original tables. This enables efficient data
access, at the cost of data being outdated. Some of the common database
vendors that generate materialized view or materialized query tables
are Oracle Materialized View (MV) or DB2 Materialized
Query Table (MQT), which the EJB to RDB mapping tools do not support.
In addition, you cannot create a regular view to a materialized view,
this is also known to fail with the EJB to RDB mapping tools.
- When mapping EJBs with inheritance, you can use a single table
mapping strategy where all fields from all beans in the hierarchy
are mapped to one table, or a root-leaf strategy where each bean has
a unique table to store attributes unique to that bean. You can also
use a mixed strategy where some beans are stored in its parent table
as in single table and other beans are stored in separate tables as
in root-leaf.
If you have a mixed strategy, you must follow the
following rule when using EJB queries: If a bean is mapped to its
parent table, then all of its descendants, siblings, and descendants
of its siblings must follow the same strategy. For example, given
a hierarchy illustrated below, if ChA1 is mapped to the same table
as ChA, then ChA3, ChA2 and ChA4 must also be mapped to the same table.

Arabic characters not supported for Java files and enterprise beans
Do not
use Arabic characters in names for Java files,
enterprise beans, or access beans.