EJB deployment tool
Before you can successfully run your enterprise beans on either a test or production server, you need to generate deployment code for the enterprise beans. You can do this using the EJB deployment tool. You can either use the command-line interface that it provides or you can invoke it from the workbench.
Using the command line, you can run a build process overnight and have the deployment tool automatically invoked to generate your deployment code in batch mode.
The EJB deployment tool is invoked using the ejbdeploy command, which accepts an input EJB JAR or EAR file that contains one or more enterprise beans. It then generates an output deployed JAR or EAR file (depending on the type of the input file) that contains deployment code in the form of .class files.
The EJB deployment tool supports both top-down and meet-in-the-middle mappings, EJB single and multiple table inheritance, and relationships. It supports the use of converters, which translate a database representation to a Java object type, and composers, which are used to map a single complex bean field to multiple database columns. The EJB deployment tool now supports the following levels of access intent (where AccessIntent is a WebSphere extension):
- wsPessimisticUpdateWeakestLockAtLoad
- wsPessimisticUpdate
- wsPessimisticUpdate-NoCollision
- wsPessimisticUpdate-Exclusive
- wsPessimisticRead
- wsOptimisticUpdate
- wsOptimisticRead
The EJB deployment tool generates all the code that is necessary for all access intents. That is, you do not have to specify an option for this to happen.
The persistence manager is a run-time component that is responsible for providing the implementation of the persistent fields and relationships, as well as all data access to the underlying persistent store. The isolation level is a data integrity feature that determines how data is locked from other processes while it is being accessed.
The access type is of primary interest because the combination of concurrency (which is the shared use of resources by multiple processes at the same time) and access type determines the isolation level for the persistence manager.
The access type thus controls the lock type, and duration of locks obtained when bean data is read from the database. A pessimistic access type indicates to hold locks for the duration of the transaction under which the data loads. An optimistic type indicates to drop locks immediately after the data is read from the backend. A read type indicates that the run time must not allow updates to the data; any attempt to do so on data read under a read type results in an exception. Update types permit you to change data.
For 2.x EJB projects only, mapping to multiple back-end databases is also supported. The schemas and the generated DDL file are stored in the following directory of the JAR or EAR file:
EJBname\ejbModule\META-INF\backends\backend_id\schemaname.schxmi
EJBname\ejbModule\META-INF\backends\backend_id\tablename.ddl
If multiple backends exist and you did not set the current back-end ID in the EJB deployment descriptor, the EJB deployment tool will default to the first back-end ID that appears as a folder in the respective META-INF\backends directory as described earlier. If you map to a single backend database, then the generated DDL file will appear both in the directory as described above and also in the META-INF folder.
Generating EJB deployment code from the workbench
Before you can successfully run your enterprise beans on either a test or production server, you need to generate deployment code for the enterprise beans.Generating EJB deployment code from the command line
The EJB deployment tool provides a command-line interface that you can use to generate enterprise bean deployment code. Before you can successfully run your enterprise beans on either a test or production server, you need to generate deployment code for the enterprise beans.Deploying EJB applications using SQLJ for data access
Deploying enterprise beans which use SQLJ as their persistence mechanism is more complicated than regular deployment. As part of the generation of deployment code, one or more SQLJ customization profiles will be created. You can then run the DB2 SQLJ profile customizer against the customization profiles to produce static SQL in the database.Deleting deployment code
In certain cases, you may want to delete only the generated deployment code for the selected enterprise beans without deleting all the other artifacts such as the EJB metadata, the bean classes and the access bean classes that compose the bean.
Related concepts
DB2 SQLJ profile customizer
Related reference
The ejbdeploy command
Access intent and isolation levels
Limitations of EJB deployment
Message format for EJB validation