Express (Distributed operating systems), v8.0 > Reference > Command-line utilities > EJB deployment tool > Reference
Limitations of EJB deployment
This topic outlines current, known limitations and restrictions for EJB deployment.
Run older versions of code generation tools
This limitation is applicable to applications that uses WebSphere extensions and bindings. However, if the 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 WAS 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.
Run the ejbDeploy command can generate compilation errors for DB2 V9 for z/OS
If we 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 Run 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 we 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.
- 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.
- 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. We 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 we have a mixed strategy, 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.
Feedback