Example of Deploying Session and Entity EJBs


This example from Chapter 2 (displaying this book’s authors) has been revised for use in this chapter. To summarize the changes, the new example uses the following:

  • A session bean to query and fetch the authors information for the JSP to display

  • A CMP entity bean to represent data stored in a relational database

The relational database you will use is the Derby embedded database included as part of the Geronimo distribution. You can use another relational database if you like, with little impact on the example code. A later section shows how to create a system database pool with any RDBMS supporting JDBC.

Table 12-2 shows the software components in this example.

Table 12-2: Software Components in the Deployment Example
Open table as spreadsheet

Component

Description

authors.jsp

The Presentation layer Web component that generates the Web page to display the list of authors. The data to display is obtained from the session EJB indirectly, via AppController (described next).

AppController

A Java class that acts as controller (as in the Model-View-Controller design pattern). It fetches data from the model (session bean) and attaches the data as an attribute, then the request with attribute is passed to authors.jsp for display.

AuthorsBean

A session EJB that the AppController accesses to obtain the authors information. Internally, it uses the AuthorEntityCMPBean to obtain author information from the RDBMS.

AuthorEntityCMPBean

An entity EJB that uses CMP2 supported by Geronimo to access RDBMS information.

Deploying Session and CMP Entity Beans

The following listing shows the J2EE ejb-jar.xml deployment descriptor for the session EJB:

 <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN'  'http://java.sun.com/dtd/ejb-jar_2_0.dtd'> <ejb-jar>   <enterprise-beans>       <session>           <display-name>Authors Stateless Session Bean Local Interfaces</display- name>           <ejb-name>AuthorsCMPEJB</ejb-name>           <local-home>com.wrox.progeronimo.AuthorsHomeLocal</local-home>           <local>com.wrox.progeronimo.AuthorsLocal</local>           <ejb-class>com.wrox.progeronimo.AuthorsBean</ejb-class>           <session-type>Stateless</session-type>           <transaction-type>Container</transaction-type>       <ejb-ref>         <ejb-ref-name>AuthorBean</ejb-ref-name>          <ejb-ref-type>Entity</ejb-ref-type>           <home>com.wrox.progeronimo.AuthorHome</home>           <remote>com.wrox.progeronimo.AuthorRemote</remote>        </ejb-ref>       </session>   </enterprise-beans> </ejb-jar> 

This deployment descriptor is similar to ejb-jar.xml from Chapter 2, with an additional <ejb-ref> element referencing the CMP2 entity bean that is used to access the Derby database. The session bean is bundled in its own authors-ejbs.jar archive. Identically to the example from Chapter 2, the Web-tier servlet will be accessing this session bean via its local interface.

The CMP2 entity bean is packaged in an independent EJB JAR file called authors-cmpejbs.jar and contains the following ejb-jar.xml deployment descriptor:

 <?xml version="1.0" encoding="US-ASCII"?> <ejb-jar xmlns="http://java.sun.com/xml/ns/j2ee"     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"     xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee     http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd"     version="2.1">     <description>         Wrox Professional Geronimo CMP Entity Bean Example.     </description>     <enterprise-beans>         <entity>             <description>                 Name of authors              </description>             <ejb-name>AuthorBean</ejb-name>             <home>com.wrox.progeronimo.AuthorHome</home>             <remote>com.wrox.progeronimo.AuthorRemote</remote>             <ejb-class>com.wrox.progeronimo.AuthorEntityCMPBean</ejb-class>             <persistence-type>Container</persistence-type>             <prim-key-class>java.lang.String</prim-key-class>             <reentrant>false</reentrant>             <cmp-version>2.x</cmp-version>             <abstract-schema-name>AuthorBeanCMP2</abstract-schema-name>             <cmp-field><field-name>id</field-name></cmp-field>             <cmp-field><field-name>firstName</field-name></cmp-field>             <cmp-field><field-name>lastName</field-name></cmp-field>             <primkey-field>id</primkey-field>             <resource-ref>                 <description>                     This is a reference to a JDBC database.                  </description>                 <res-ref-name>jdbc/basic/entityDatabase</res-ref-name>                 <res-type>javax.sql.DataSource</res-type>                 <res-auth>Container</res-auth>             </resource-ref>             <query>                 <query-method>                     <method-name>findByName</method-name>                     <method-params>                         <method-param>java.lang.String</method-param>                     </method-params>                 </query-method>                 <ejb-ql>                     <![CDATA[SELECT OBJECT(a) FROM AuthorBeanCMP2 AS a WHERE a.firstName = ?1]]>                 </ejb-ql>             </query>             <query>                 <query-method>                     <method-name>findEmptyCollection</method-name>                     <method-params/>                  </query-method>                 <ejb-ql>                     <![CDATA[SELECT OBJECT(a) FROM AuthorBeanCMP2 AS a WHERE 1 = 0]]>                 </ejb-ql>             </query>             <query>                 <query-method>                     <method-name>findAll</method-name>                     <method-params/>                 </query-method>                 <ejb-ql>                     <![CDATA[SELECT OBJECT(a) FROM AuthorBeanCMP2 AS a]]>                 </ejb-ql>             </query>         </entity>     </enterprise-beans> </ejb-jar> </ejb-jar>

In this ejb-jar.xml deployment descriptor, the mapping from the CMP EJB’s members and the fields in a database are described in detail. A reference to an external database connections pool is specified - jdbc/basic/entityDatabase. EJB query methods and their associated EJB/QL query statements are also specified here. (A discussion of the powerful J2EE CMP2 capabilities is beyond the scope of this book.)

The following section explores more details on the ejb-jar.xml file and its most frequently used component elements.

The ejb-jar.xml Deployment Descriptor

EJBs consist of Java class files that are coded to the EJB 2.0 or EJB 2.1 specification. They are bundled into JAR files for deployment. Each EJB JAR file is obliged to contain a J2EE deployment descriptor. This deployment descriptor must be named ejb-jar.xml. The general format of this descriptor is:

 <ejb-jar>   <description>    ....   </description>  <enterprise-beans>         <session>           ... session bean description and references...        </session>          .....       <entity>           ... entity bean description and references...       </entity>       .....       <message-driven>            ... message driven bean description and references...       </message-driven>       ...    </enterprise-beans>    <relationships>        ... description relationship between EJBs ...     </relationships>     <assembly-description>         ... for assembly tool use...    </assembly-description>    <ejb-client-jar>             ... path to EJB client JAR ...     </ejb-client-jar> </ejb-jar>       

The root element is <ejb-jar>. It can contain a description of the file (including a display name), as well as a small and large icon to represent the EJB archive.

Every EJB contained in the JAR must then be described within the <enterprise-beans> subelement. More details on the content of this element are discussed in the next section. After the <enterprise- beans> description, there is a description of relationship (managed by the container). The last two optional supplements are an assembly descriptor and the name of an EJB client JAR.

Describing EJBs

To describe the EJBs contained in an EJB JAR, the <enterprise-beans> element is used within ejb-jar.xml.

The <enterprise-beans> element can contain the subelements shown in Table 12-3.

Table 12-3: The <enterprise-beans> Element in ejb-jar.xml
Open table as spreadsheet

Subelement

Description

<session>

The content describes a session bean.

<entity>

The content describes an entity bean. CMP entity beans may have extensive description within this element.

<message-driven>

The content describes an MDB. MDBs are fundamentally different than session and entity beans as far as configuration. One major difference is that they can implement any interface and are not restricted to EJBHome interface.

Common Elements in Both Session and Entity EJBs

These subelements are part of both the description of a session bean (the <session> tag) and an entity bean (the <entity> element). Table 12-4 shows common elements for session beans and EJBs.

Table 12-4: Common Elements for Session Beans and EJB
Open table as spreadsheet

Subelement

Description

<ejb-name>

The name of the EJB, used by the container to locate the EJB.

<home>

The fully qualified Java name for the remote home interface to the EJB, if the EJB supports a remote home interface. This element and the next must exist together.

<remote>

The fully qualified Java name for the remote interface to the EJB, if the EJB supports a remote interface. This element and the previous must exist together.

<local-home>

The fully qualified Java name for the local home interface to the EJB, if the EJB supports local home interface. This element and the next must exist together.

<local>

The fully qualified Java name for the local interface to the EJB, if the EJB supports a local interface. This element and the previous one must exist together.

<service-endpoint>

The fully qualified Java name for the service endpoint interface of the EJB, if the EJB supports Web service access. Only stateless session beans can be exposed as Web services.

<ejb-class>

The fully qualified Java class name for the implementation of the EJB.

Session Bean

In addition to the common subelements described in Table 12-4, the <session> bean element also contains the additional subelements shown in Table 12-5.

Table 12-5: Session Bean Elements
Open table as spreadsheet

Subelement

Description

<session-type>

Specifies the session bean’s state management type - either Stateful or Stateless.

<transaction-type>

Specifies who is responsible for transaction management, can be either Bean or Container.

<security-role-ref>

Contains a reference used in the code to refer to a security role. Subelements can optionally provide a description and a link to a security role. See Chapter 16 for Geronimo security coverage.

<security-identity>

Has either a <use-caller-identity> or <run-as> subelement. Specifies if the EJB’s method should be called using the caller’s identity or a specific run-as identity associated with a security role. See Chapter 16 for Geronimo security coverage.

Entity Bean

In addition to the common subelements described in Table 12-5, the <entity> bean element also contains the additional subelements shown in Table 12-6.

Table 12-6: Entity Bean Elements
Open table as spreadsheet

Subelement

Description

<persistence-type>

The entity EJB’s persistence management type, can be either bean (for Bean Managed Persistence - BMP) or container (for CMP).

<prim-key-class>

Fully qualified name of the Java class representing the type of the primary key field of the entity EJB. See <primkey-field> below.

<reentrant>

Can be true or false, indicating if the entity bean supports re-entrant access.

<cmp-version>

The version of CMP support required by the EJB (can be 1.x or 2.x).

<abstract-schema-name>

For CMP 2.x, specifies the abstract schema type of the EJB (used primarily for EJB/QL).

<cmp-field>

Specifies a container-managed field on the EJB.

<primkey-field>

Specifies the primary key field on the EJB. The field must already be specified as an <cmp-field> and must have Java type of <prim-key-class>.

<security-role-ref>

Contains a reference used in the code to refer to a security role. Subelements can optionally provide a description and a link to a security role. See Chapter 15 for Geronimo security coverage.

<security-identity>

Has either a <use-caller-identity> or <run-as> subelement. Specifies if the EJB’s method should be called using the caller’s identity or a specific run-as identity associated with a security role. See Chapter 15 for Geronimo security coverage.

Message Driven Beans (MDBs)

The structure and operations of an MDB are significantly different from those of session and entity beans. Because of this, the descriptor for an MDB is also different. Table 12-7 shows the subelements of the <message-driven> element for describing an MDB in an EJB JAR file.

Table 12-7: Message Driven Bean (MDB) Elements
Open table as spreadsheet

Subelement

Description

<ejb-name>

The name of the EJB.

<ejb-class>

The Java class that implements the MDB.

<messaging-type>

Fully qualified Java interface name of the listener interface implemented by the MDB. If not specified, it defaults to javax.jms.MessageListener.

<transaction-type>

Specifies who is responsible for transaction management (can be either Bean or Container).

<message-destination-type>

The type of message destination that is associated with the MDB (can be queue or topic).

<message-destination-link>

Refers to a <message-destination-name> defined elsewhere in the same deployed module.

<activation-config>

Name-value property pairs for the configuration of the environment in which the MDB will be invoked.

<security-identity>

Has either a <use-caller-identity> or <run-as> subelement. Specifies if the MDB should be invoked using the caller’s identity or a specific run-as identity associated with a security role. See Chapter 15 for Geronimo security coverage.

Other Elements in ejb-jar.xml

One other subelement in ejb-jar.xml that may be worth taking a look at is the <assembly-description> subelement. This element describes the assembly of the application module. Typically, this element is edited using an assembly tool. Table 12-8 examines the pertinent subelements.

Table 12-8: <assembly-description> Subelements
Open table as spreadsheet

Subelement

Description

security-role

Definition of security role for this module.

method-permission

Specifies the security role that is allowed to invoke each protected method. The role referenced must have a <security-role> defined.

container-transaction

Specifies how transaction should be handled for method invocation. A <trans-attribute> subelement can contain NotSupported, Supports, Required, RequiredNew, Mandatory, or Never. See Table 12-11.

message-destination

Defines message destinations and associated <message-definition- name> that are used within the module (for example, referenced by the MDB).

exclude-list

A list of methods that should be excluded from invocation.

The openejb-jar.xml Deployment Plan

The openejb-jar.xml is the Geronimo-specific deployment plan used to mapped referenced resources and EJBs in the deployment descriptor. For our example, the following is the openejb-jar.xml:

 <?xml version="1.0"?> <openejb-jar xmlns="http://www.openejb.org/xml/ns/openejb-jar-2.1"> <dep:environment xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.1">     <dep:moduleId>       <dep:groupId>wrox</dep:groupId>       <dep:artifactId>ejbcmp2</dep:artifactId>       <dep:version>1.1</dep:version>       <dep:type>car</dep:type>     </dep:moduleId>     <dep:dependencies>       <dep:dependency>         <dep:groupId>console.dbpool</dep:groupId>         <dep:artifactId>AuthorConnectionsPool</dep:artifactId>         <dep:version>1.0</dep:version>         <dep:type>rar</dep:type>       </dep:dependency>     </dep:dependencies>     </dep:environment>  <cmp-connection-factory>           <resource-link>AuthorConnectionsPool</resource-link>      </cmp-connection-factory>    <enterprise-beans>           <entity>               <ejb-name>AuthorBean</ejb-name>               <jndi-name>WroxAuthorBean</jndi-name>               <table-name>authors</table-name>               <cmp-field-mapping>                   <cmp-field-name>id</cmp-field-name>                   <table-column>authornum</table-column>               </cmp-field-mapping>               <cmp-field-mapping>                   <cmp-field-name>firstName</cmp-field-name>                   <table-column>fname</table-column>               </cmp-field-mapping>               <cmp-field-mapping>                   <cmp-field-name>lastName</cmp-field-name>                   <table-column>lname</table-column>               </cmp-field-mapping>                           <resource-ref>                   <ref-name>jdbc/basic/entityDatabase</ref-name>                   <resource-link>AuthorConnectionsPool</resource-link>               </resource-ref>           </entity>           </enterprise-beans>       </openejb-jar>

This deployment plan maps the database connections pool that the CMP EJB references to a concrete database pool (created later in this chapter) managed by Geronimo. Notice in the previous bolded code how the dependency on the Derby database connection pool is configured in the environment. This allows the Geronimo deployer to find the JCA connector classes and the driver classes.

Table 12-9 provides details on some of the frequently used elements in the openjb-jar.xml deployment plan.

Table 12-9: The openejb-jar.xml Deployment Plan
Open table as spreadsheet

Subelement

Description

import

You can have multiple import subelements. Each one specifies a Geronimo-managed configuration that should be made a parent of this current configuration.

dependency

Specifies JAR library files that this configuration is dependent on. You can have multiple dependency elements. Geronimo will look in the repository for JAR files that are specified here.

hidden-classes

Specifies classes that you want to hide for this configuration. Typically, all of the classes from parent class loaders are made available. Specifying this allows selective masking of classes from the parent.

non-overridable-classes

Specifies classes that you want to always load from a parent’s class loader, even if they exists on the local class loader.

cmp-connection-factory

Geronimo-managed CMP beans will use this factory to obtain connections to the RDBMS.

ejb-ql-connection-factory

The factory class used to create instances of the EJB-QL compiler class. This class compiles/ translates EJB-QL queries to SQL syntax. The default value is org.tranql.sql.EJBQLCompilerFactory, and it works with Derby, MySQL, and DB2, among others.

db-syntax-factory

The factory class for creating objects that implements the org.tranql.sql.DBSyntaxFacotry interface. This class is used in the transformation of CMP SQL. The default will work with all of the RDBMSs supported by Geronimo.

enforce-foreign-key-constraints

Default is false. Determines if SQL statements that modify the RDBMS will be carried out in a specific sequence to ensure that the state of foreign key constraints are consistent. Enabling this may affect data insert/update/delete performance but may be necessary for certain RDBMSs.

enterprise-beans

Specifies the resources referenced by <session> and <entity> EJBs. Used mainly for J2EE 1.3 compatibility and reference resources (such as JMS destinations) that are not available with 1.3 descriptors.

relationships

The list of container-managed relationships between EJBs.

message-destination

References a message-destination (such as JMS queues), which is used within the deployed WAR file.

security

Configures the security role mappings that will be used when deploying the module. Maps roles specified in the WAR file to roles or principals in the security realm. See Chapter 15 for more information on the use of this element.

gbean

Specifies additional GBeans that are configured and deployed with this module.

Resolving EJB References in Geronimo

Application tier components typically access business-tier EJBs to perform business logic. In addition, business-logic-based manipulation of entity beans is almost always handled using session beans. This means that many EJB JARs will have external references to other EJBs.

Unlike other application servers you may be familiar with (such as JBoss and Weblogic), Geronimo does not have a global JNDI space for resolving external references. Instead, you must wire up the references at deployment time using elements such as <ejb-link>. However, Geronimo assists in this wiring by providing built-in intelligence that can deduce the desired link under most circumstances without your creating explicit links. For example, local EJB references are matched by the home and local access interface type - and work reasonably well, as long as you do not have multiple EJBs satisfying the requirements in the same module.

Depending on the interface type of the EJBs, and where the EJB modules are located, the way Geronimo resolves references can be significantly different. Table 12-10 provides details on EJB reference resolution in Geronimo.

Table 12-10: EJB Reference Resolution in Geronimo
Open table as spreadsheet

EJB location

EJB Interface

Reference handling

In the same EAR as the Web-tier component

Local home; local interface

The Geronimo container will attempt to match the local and home interface to the EJBs available within the same EAR to determine the EJB referenced. You can also use the <ejb-link> element to gain control to the exact mapping.

In the same EAR as the Web-tier component

Remote home; remote interface

The Geronimo container will attempt to match the local and home interface to the EJBs available within the same EAR to determine the EJB referenced. You can also use the <ejb-link> element to gain control to the exact mapping.

In another deployed module

Remote home; remote interface

An EJB reference must be specified and mapped (via <ejb-link>) for each external EJB used. Be aware that the code of the EJB must be accessible to the Web-tier module through its classloader; this may involve making the configuration that it depends on its parent.

As expected, EJBs that are located within the same JAR and use local EJB interfaces are easiest to resolve- since the container knows about them at the time of deployment. This is confirmed in Table 12-10. EJBs that are located in a separately deployed module require the most work to deploy successfully-including the task of ensuring that all the classes required by the referenced EJB can be loaded.

Mapping Internal EJB References

When you are creating a geronimo-web.xml or openejb-jar.xml file, you can map (wire up) any definitions to the actual managed EJBs. To map a reference that uses a remote interface, use the following:

 <naming:ejb-ref>     <naming:ref-name>....name.... </naming:ref-name>     <naming:ejb-link>... link to ejb.... </naming:ejb-link> </naming:ejb-ref> 

To map a local reference, use:

 <naming:ejb-local-ref>     <naming:ref-name>.... name ......</naming:ref-name>     <naming:ejb-link>.... link to ejb.....</naming:ejb-link> </naming:ejb-local-ref>

This reference syntax is handy when you know that the Geronimo container can find the referenced EJB by the interface types.

Mapping External EJB References

A similar technique exists for mapping external EJB references. EJB in other modules that are addressed using remote interfaces can be mapped as follows:

 <naming:ejb-ref>     <naming:ref-name>... name of reference..... </naming:ref-name>     <naming:domain>geronimo.server</naming:domain>     <naming:server>geronimo</naming:server>     <naming:application>...applicationId...</naming:application>     <naming:module>... configId....</naming:module>     <naming:type>... type....</naming:type>     <naming:name>ejbname</naming:name> </naming:ejb-ref>

Mapping EJBs with remote interfaces is similar:

 <naming:ejb-ref>     <naming:ref-name>... name of reference..... </naming:ref-name>     <naming:domain>geronimo.server</naming:domain>     <naming:server>geronimo</naming:server>     <naming:application>...applicationId...</naming:application>     <naming:module>... configId....</naming:module>     <naming:type>... type....</naming:type>     <naming:name>ejbname</naming:name> </naming:ejb-ref>

General Configuration Concerns

When you are deploying EJBs, keep in mind the following:

  • All EJBs must have <ejb-ref> or <ejb-local-ref> associated with them and should have a mapping to a managed EJB in the openejb-jar.xml deployment plan.

  • You must ensure that any external classes that you need (even for dependent components) can be loaded - this typically means placing them in the repository or making the configuration that contains them your parent configuration.

  • Any role-based security declarations in deployment descriptor must be mapped to the users and/or groups of the Geronimo security realm that you plan to use (see Chapter 15).

  • Any reference to external databases (such as the database and table to back a CMP EJB) must be mapped to a running database connection pool. Database connections pools are deployed instances of JCA resource adapters for JDBC access to relational databases.

  • For any reference to JMS message destinations, the destinations must be created and deployed as admin objects on Geronimo. Any reference to JMS connection factories must be mapped to a running instance of a connection factory hosted on the Geronimo server.

Informing the Container of Components to Deploy

To inform Geronimo of components within the EAR file to deploy, you use two deployment descriptors. The first one is a standard J2EE deployment descriptor - application.xml. The following is the application.xml for this EAR file. The application.xml must be placed in the EAR file’s META-INF directory.

 <application         xmlns="http://java.sun.com/xml/ns/j2ee"        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"        xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee        http://java.sun.com/xml/ns/j2ee/application_1_4.xsd"        version="1.4"        >      <module>         <ejb>authors-ejbs.jar</ejb>     </module>     <module>         <ejb>authors-cmpejbs.jar</ejb>     </module>     <module>         <web>             <web-uri>authorscmp2.war</web-uri>             <context-root>/progeron</context-root>         </web>     </module> </application>

This application.xml file tells Geronimo that there are three modules in the EAR file to deploy, including authors-ejbs.jar (the session bean), authors-cmpejbs.jar (the entity bean), and authorscmp2.war (the Web-tier servlet and JSP).

In the application.xml, the authorscmp2.war component is also provided with a <context-root> of /progeron. This allows you to access the application later via http://localhost:8080/progeron/authors.cgi later.

In addition to the J2EE standard application.xml, a Geronimo-specific deployment plan is also included. This plan is called geronimo-application.xml. This plan contains the following:

 <application         xmlns="http://geronimo.apache.org/xml/ns/j2ee/application-1.1">    <environment>    <moduleId>       <groupId>wrox</groupId>       <artifactId>ejbcmp2</artifactId>       <version>1.1</version>       <type>car</type>     </moduleId>   </environment> </application> 

This geronimo-application.xml file simply provides a moduleId for the deployed module. This file can either be located in the META-INF directory of the EAR (alongside the application.xml file already there) or be specified externally during deployment, and not be a part of the EAR file at all.

The benefit of keeping it external is the fact that it can be changed externally without the need to reassemble the EAR file. The disadvantage of keeping it externally is that you must track and maintain the two files instead of one single convenient EAR bundle.

Creating Derby Databases for the CMP Entity Bean

Next, you need to create the Derby database that the AuthorBean will be linked to. This can be accomplished via the Web console.

If you select Embedded DBDB Manager from the menu, you can add the new wroxuathors database using the RUN SQL portlet. Just enter wroxuathors in the Create DB field and click the Create button, as shown in Figure 12-5.

image from book
Figure 12-5: Creating the wroxauthors database for the CMP bean

Once you have created the wroxauthors database, you can add an authors table into it. You can also populate it with the authors data. This can be accomplished in the same RUN SQL portlet. First, ensure that the Use DB: field has wroxauthors selected. Then, enter SQL statements into the SQL Command/s: field, and click the Run SQL button. Figure 12-6 shows the commands to create and populate the authors table.

image from book
Figure 12-6: Creating and populating tables in the wroxauthors database

In Figure 12-6, note that the wroxauthors database is listed in the database list of the DB Viewer portlet. This is confirmation that database creation is successful.

Once you have successfully run the SQL commands in Figure 12-6, click on the Application link of the View Tables column in the DB Viewer portlet (the one next to the wroxauthor database). This link shows the application tables in the database. You will see a listing of the available tables. Select the authors table. This will display and verify the contents of the authors table you’ve just created, as shown in Figure 12-7.

image from book
Figure 12-7: Viewing the content of the authors table in the Derby wroxauthors database

Configuring Transactions

J2EE 1.4 supports declarative transactions for EJBs managed by compatible containers. Geronimo fully supports declarative transactions (also called container-managed transactions) for all its EJBs - session beans, entity beans, or Message Driven Beans.

The main benefit of declarative transaction, managed by the container, is that it frees the software developers from having to intermix complex transaction management code in their software component. Declarative transactions defer the decision of when to set transaction boundary from development time to deployment time. They also enable the same components to be configured with different transaction boundaries, depending on the requirements of the application.

To control the transaction boundary for container-managed transactions, a Geronimo administrator can do so by setting deployment descriptor attributes. These are XML elements in the standard ejbjar.xml J2EE deployment descriptor. The attributes that controls transaction boundaries are primarily the following:

<transaction-type>

<container-transaction>

<trans-attribute>

The following discussion describes how each of these elements is used.

J2EE Transaction Attributes for EJBs

The transaction attributes (specified in the J2EE 1.4 specifications) attempt to cater to most application scenarios that exist in the real world. Table 12-11 shows these attributes.

Table 12-11: J2EE Transaction Attributes for EJBs
Open table as spreadsheet

Attribute

Description

RequiresNew

If the caller is in a transaction, it is suspended while this method call is made. A new transaction is always started for this call.

Required

If the caller has a transaction, use it. Otherwise, start a new one.

Mandatory

Insists that the caller is in a transaction. If the caller is in a transaction, use it. If the caller is not in a transaction, this is an error condition and an exception will be thrown.

NotSupported

If the caller is in a transaction, that transaction is suspended while the call is made. The call is made outside of any transaction.

Supports

Go with the flow. If the caller has a transaction, that transaction is used. If the caller is not in a transaction, this call is made outside of any transaction.

Never

Insists that the caller not be in a transaction. If the caller is in a transaction, this is an error condition and an exception will be thrown. Otherwise, if the caller is not in a transaction, then make this call outside of any transaction.

Transaction attributes can either be specified at the bean level (which means that they will apply to every method exposed by an EJB) or be specified on a per-method level (providing a finer-grained control over transaction management in an application).

To apply transaction attributes on a bean level, they can be configured in a J2EE ejb-jar.xml deployment descriptor as follows:

 <container-transaction>           <method>               <ejb-name>ProGeronEJB</ejb-name>               <method-name>*</method-name>           </method>           <method>               <ejb-name>ActiveManageEJB</ejb-name>               <method-name>*</method-name>           </method>           <trans-attribute>Required</trans-attribute> </container-transaction>

The transaction attributes can be specified at the method level, as shown here:

 <container-transaction>      <method>          <ejb-name>ProGeronEJB</ejb-name>          <method-name>getAuthorById</method-name>         <method-params>             <method-param>java.lang.Integer</method-param>         </method-params>     </method>     <trans-attribute>NotSupported</trans-attribute> </container-transaction>

Any attribute specified at the method level will override the any attribute set at the bean level.

Geronimo implements Java Transaction API 1.0 (JTA 1.0). Both container-managed transactions and bean-managed transactions (programmatic control by developers) are supported. The Geronimo transaction manager is active whenever the server is started.

Database pools can be configured to work with local transaction (local to a single database instance) or with distributed transaction via XA (working across multiple database instances). Distributed transactions across multiple resource managers (such as multiple database instances) are managed via a two-phase commit protocol.

A full discussion of the application of J2EE transactions is beyond the scope of this book.




Professional Apache Geronimo
Professional Apache Geronimo (Wrox Professional Guides)
ISBN: 0471785431
EAN: 2147483647
Year: 2004
Pages: 148

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net