Common Characteristics of EJB

This chapter describes the general characteristics of EJBs in JEUS environment.

This chapter does not cover the EJB standard. It only provides information that is required to use EJBs in the JEUS environment. For information about EJB deployment, refer to EJB Modules.

1. Overview

This section discusses EJB types and their DD configurations.

EJB type

The following EJB types are supported in JEUS.

Stateless Session Bean : Session Bean
Stateful Session Bean : Session Bean
BMP Entity Bean : Entity Bean
CMP 1.1 & CMP 2.x Entity Bean : Entity Bean
Message-Driven Bean : Message Driven Bean(MDB)

This chapter describes characteristics and configurations common to all bean types. In the previous list, you can find reference to additional information about each type.

Since Entity Bean has been replaced by JPA since EJB 3.0 (refer to JEUS JPA Guide for information about JPA), it is not recommended to use it. Entity Bean is only supported for backward compatibility.

Deployment Descriptor Configuration by EJB Type

JEUS EJB Deployment Descriptor (hereafter JEUS EJB DD) is a generic XML file named jeus-ejb-dd.xml, and it is placed in the META-INF directory of an EJB JAR file. For more information about JEUS EJB DD, refer to EJB Modules.

The following table outlines the functions and components that can be configured in JEUS EJB DD ("@" indicates that the entity can be configured using annotation). The items in the leftmost column represent the actual configurable XML tags of a JEUS EJB DD. The next six columns show whether the component is applicable to each of the EJB types.

Configurable Item	Stateless	Stateful	BMP	CMP1.1	CMP2.0	MDB
1. EJB name @	√	√	√	√	√	√
2. Export name @	√	√	√	√	√
3. Local export name @	√	√	√	√	√
4. Export port	√	√	√	√	√
5. Export IIOP switch	√	√	√	√	√
6. use-access-control	√	√	√	√	√	√
7. Run-as Identify	√	√	√	√	√	√
8. Security CSI Interop.	√	√	√	√	√	√
9. Env. Refs @	√	√	√	√	√	√
10. EJB refs @	√	√	√	√	√	√
11. Resource Refs @	√	√	√	√	√	√
12. Resource env. Refs @	√	√	√	√	√	√
13. Thread ticket pool settings	√	√`	√	√	√	√
14. Clustering settings @	√	√	√	√	√
15. HTTP Invoke	√	√	√	√	√
16. Pooling Bean Switch		√
17. Object management	√	√	√	√	√	√
18. Persistence Optimize			√	√	√
19. CM persistence opt.				√	√
20. Schema info				√	√
21. Relationship map					√
22. Connect. fact. name						√
23. MDB resource adaptor						√
24. Destination @						√
25. JNDI SPI settings						√
26. Max messages						√
27. Activation Config @						√
28. Durable Timer Service	√		√	√	√	√

Configurable Item

Stateless

Stateful

BMP

CMP1.1

CMP2.0

MDB

1. EJB name @

√

2. Export name @

√

3. Local export name @

√

4. Export port

√

5. Export IIOP switch

√

6. use-access-control

√

7. Run-as Identify

√

8. Security CSI Interop.

√

9. Env. Refs @

√

10. EJB refs @

√

11. Resource Refs @

√

12. Resource env. Refs @

√

13. Thread ticket pool settings

√

√`

√

14. Clustering settings @

√

15. HTTP Invoke

√

16. Pooling Bean Switch

√

17. Object management

√

18. Persistence Optimize

√

19. CM persistence opt.

√

20. Schema info

√

21. Relationship map

√

22. Connect. fact. name

√

23. MDB resource adaptor

√

24. Destination @

√

25. JNDI SPI settings

√

26. Max messages

√

27. Activation Config @

√

28. Durable Timer Service

√

The previous table is partitioned as follows:

Items 1 through 16 are common to all six EJB types (Items 2-5 and 14-16 do not apply to MDB). All these items are discussed in this chapter.
Items 7 (run-as Identify), 8 (security interoperability), and 14 (clustering) are common to all EJB types, and are discussed in separate chapters titled Configuring EJB Security, EJB Interoperability and RMI/IIOP, and EJB Clustering respectively.
Item 17 only applies to stateful session beans and are discussed in Session Bean.
Item 18 (object management) is common to all six EJB types, but it varies slightly for each EJB type. Basic information about this item is discussed in Session Bean, and the differences in each chapter.
Items 19 through 22 only apply to entity beans. They will be discussed in Entity Bean.
Items 23 through 28 only apply to message-driven beans (MDB). MDBs are covered in Message Driven Bean(MDB).
Item 29 is common to beans (all beans excluding stateful session bean) that support the Timer Service included in EJB specification. For more information, refer to the EJB Timer Service.

2. Configuring EJBs

All the EJB settings are configured in the jeus-ejb-dd.xml file, the JEUS EJB DD file. The parent XML tag is <jeus-bean> for all bean types.

The next section will describe settings applicable to XML parent tags for the five EJB types. Other tags outside the <beanlist> have already been discussed in EJB Modules. For more information about specific XML parent tags (bean type), refer to the next chapters in this guide.

For information about clustering settings, refer to EJB Clustering.

2.1. Configuring the Basic Environment

The following settings are only for JEUS, and are defined in the jeus-ejb-dd.xml file. For more information about the file, refer to EJB Modules.

<ejb-name>
- It uses the <ejb-name> value from the ejb-jar.xml file, or the "name" value of @Stateless, @Stateful, and @MessageDriven annotations in the implementation class.
<export-name>
- It has to have a unique name within the system to be registered to JNDI.
- If this element is not defined in the DDs, either the mappedName attribute value of @Stateless or @Stateful annotation, or the <mapped-name> value in ejb-jar.xml is applied.
  
  If none is specified, a Remote Business Interface name is used as the default value. But the default value is applied only when there is one Remote Business interface and no Remote Home Interface, or vise versa. Otherwise, the deployment fails because the JNDI name cannot be determined.
- The priority is as follows:
  1. <export-name> of jeus-ejb-dd.xml
  2. <mapped-name> of ejb-jar
  3. mappedName of @EJB
<local-export-name>
- It has to have a unique name within the system to be registered to JNDI.
- It is applied to the mappedName attribute of @EJB annotation when this element is not configured in DD. If remote business interface exists, '_Local' is attached to this value.
  
  If neither exists, the local business interface name is used as the default value. But the default value is applied only when there is one Local Business interface and no Local Home Interfaces, or vise versa. Otherwise, an exception occurs because the JNDI name cannot be found.
- The priority is as follows:
  1. <local-export-name> of jeus-ejb-dd.xml
  2. If a remote business interface exists, <mapped-name>+ _Local of ejb-jar.xml
    
    If a remote business interface does not exist, <mapped-name> of ejb-jar.xml
  3. If a remote business interface exists, mappedName + _Local of @EJB
    
    If a remote business interface does not exist, mappedName of @EJB

<export-port>

This setting is used when RMI service port needs to be specified explicitly.

It is useful when system access is possible only through a certain port because of a firewall. The value of this tag should be same as the firewall’s allowed port. If a value is not specified, ports are applied according to the system properties as follows:

Tag	Description
jeus.ejb.exportPort	Determines export ports of EJBs whose <export-port> is not specified for a specific EJB in jeus-ejb-dd.
jeus.rmi.usebaseport	true: Indicates MS base port is used. false: Indicates MS base port + 7 is used.

Tag

Description

jeus.ejb.exportPort

Determines export ports of EJBs whose <export-port> is not specified for a specific EJB in jeus-ejb-dd.

jeus.rmi.usebaseport

true: Indicates MS base port is used.
false: Indicates MS base port + 7 is used.

<export-iiop>
- If this setting is activated, it enables the interfaces of the bean to be exported to COS naming server as IIOP stubs and skeletons. This enables all clients, who can access IIOP, to access the bean.
<use-access-control>
- This Boolean element determines whether a method execution is monitored by Java SE security manager according to Jakarta EE principal. For more information, refer to JEUS Security Guide and JACC specification (default: false).

The following examples show how the previous settings can be applied to the session bean classes and DDs. Elements of corresponding annotations and DDs are displayed in bold.

Stateful Session Bean Class and DD: <CounterEJB.java>

package ejb.basic.statefulSession;

@Stateful(name="counter", mappedName="counterEJB")
public class CounterEJB implements Counter, CounterLocal
{
   private int count = 0;

   public void increase()
   {
      count++;
   }
 ...
}

Stateful Session Bean Class and DD: <jeus-ejb-dd.xml>

<jeus-ejb-dd>
    . . .
    <beanlist>
        <jeus-bean>
            <ejb-name>counter</ejb-name>
            <export-name>counterEJB</export-name>
            <local-export-name>counterEJB_Local</local-export-name>
            <export-port>7654</export-port>
            <export-iiop/>
            . . .
        </jeus-bean>
        . . .
    </beanlist>
    . . .
</jeus-ejb-dd>

2.2. Configuring Thread Ticket Pools

The following figure illustrates the concept of EJB thread ticket pool (hereafter TTP).

If there is a client request, it is assigned with a new RMI thread. If the number of assigned threads is greater than the maximum value, the request waits for an available thread.

TTP State Chart

As you can see in the figure, a thread pool contains thread tickets (hereafter TT). One TT permits one client thread to access the EJB engine. When a client request arrives, one TT is drawn from the TP and assigned to the client. This implies that each client thread will be assigned to one EJB object that will relay the request to an actual EJB instance. An EJB object is thus an object that lives in the EJB engine and manages the connection between an EJB client and an actual EJB instance.

If more client requests arrive than there are TTs in the thread ticket pool, the new requests must wait until a TT is returned to the pool. If the waiting period exceeds ten minutes, it throws a RemoteException due to a timeout.

TTs are returned to TTP when the client gets disconnected after an EJB process terminates (for stateless session bean), or a connection timeout occurs. Each remote-call enabled EJB component contains a TTP. There are also connection and bean pools. A bean pool, instead of a TTP, should be configured for an MDB.

For more information about connection and bean pools, refer to Session Bean and Entity Bean. For more information about using bean pool in MDBs, refer to Message Driven Bean(MDB).

TT of EJB is configured in the <thread-max> element of the root XML tag of the bean. This value represents the maximum number of allowable threads that can operate in each EJB, in other words, the maximum number of TT. The default value is 100. If the number of client requests in a queue is larger than this value, new requests have to wait until a running job is finished and the TT is returned to the pool. If the waiting period exceeds ten minutes, it throws a RemoteException due to a timeout.

The following shows how to configure a BMP bean as above.

Configuring a BMP Bean: <jeus-ejb-dd.xml>

<jeus-ejb-dd>
    . . .
    <beanlist>
        <jeus-bean>
            . . .
            <thread-max>200</thread-max>
            . . .
        </jeus-bean>
        . . .
    </beanlist>
    . . .
</jeus-ejb-dd>

2.3. Configuring and Mapping External References

External references that the bean uses can be configured through annotation or JNDI export name in jeus-ejb-dd.xml, which is mapped to the reference name used in ejb-jar.xml. In the actual system, all defined external references must be mapped to JNDI export name. Annotations or all the external references defined in ejb-jar.xml must be mapped to relevant tags in jeus-ejb-dd.xml using the JNDI export-name used in the actual system.

The following describes the reference tags of ejb-jar.xml and JEUS EJB DD files.

ejb-jar.xml Tag	jeus-ejb-dd.xml Tag	Description
<env-entry>	<env>	Defines or ignores the EJB environment configuration.
<ejb-ref>	<ejb-ref>	Binds an EJB reference to an actual export name.
<resource-ref>	<res-ref>	Binds an external resource manage reference to an actual export name.
<resource-env-ref>	<res-env-ref>	Binds a managed object reference to an actual export name.
<message-destination-ref>	<message-destination-ref>	Binds a message destination reference to an actual export name.
<service-ref>	<service-ref>	Binds a webservice endpoint reference to an actual export name.

ejb-jar.xml Tag

jeus-ejb-dd.xml Tag

Description

<env-entry>

<env>

Defines or ignores the EJB environment configuration.

<ejb-ref>

Binds an EJB reference to an actual export name.

<resource-ref>

<res-ref>

Binds an external resource manage reference to an actual export name.

<resource-env-ref>

<res-env-ref>

Binds a managed object reference to an actual export name.

<message-destination-ref>

Binds a message destination reference to an actual export name.

<service-ref>

Binds a webservice endpoint reference to an actual export name.

The following child tags must be configured for every <env> tag has.

Tag	Description
<name>	Name of env. Same value as the <env-entry-name> defined in the ejb-jar.xml.
<type>	Full Java class name corresponding to the data type of the value. Basic data types use a wrapper class.
<value>	Specifies actual value of env.

Tag

Description

<name>

Name of env. Same value as the <env-entry-name> defined in the ejb-jar.xml.

<type>

Full Java class name corresponding to the data type of the value. Basic data types use a wrapper class.

<value>

Specifies actual value of env.

Other three tags (<ejb-ref>, <res-ref>, and <res-env-ref>) have several <jndi-info> child tags. These tags, in turn, have to set the following child tags to map JNDI export name to reference.

Tag	Description
<ref-name>	Reference name defined in EJB source code and ejb-jar.xml. <ejb-ref> and <res-env-ref> are equivalent to <ejb-ref> and <resource-env-ref>, respectively, in ejb-jar.xml.
<export-name>	Used when an entity or object is exported to JNDI.

Tag

Description

<ref-name>

Reference name defined in EJB source code and ejb-jar.xml. <ejb-ref> and <res-env-ref> are equivalent to <ejb-ref> and <resource-env-ref>, respectively, in ejb-jar.xml.

<export-name>

Used when an entity or object is exported to JNDI.

<ref-name> and <export-name> tags must be same with the names defined in ejb-jar.xml.

The following is an example of annotation and XML that illustrates how to map external references to JNDI.

Mapping External Reference to JNDI: <CounterEJB.java>

@Stateful

@EJB(name="AccountEJB", beanInterface=ejb.Account.class, mappedName="ACCEJB")
@Resource(name="jdbc/DBDS", type=javax.sql.DataSource.class, mappedName="ACCOUNTDB")
public class CounterEJB implements Counter{
    @Resource(name="minAmount")
    private int minAccount = 100;

 . . .
}

Mapping External Reference to JNDI: <ejb-jar.xml>

<ejb-jar.xml>
    . . .
    <enterprise-beans>
        <session>
            . . .
            <env-entry>
                <env-entry-name>minAmount</env-entry-name>
                <env-entry-type>java.lang.Integer</env-entry-type>
            </env-entry>
            <ejb-ref>
                <ejb-ref-name>AccountEJB</ejb-ref-name>
                <ejb-ref-type>Session<ejb-ref-type>
                <remote>ejb.Account</remote>
            </ejb-ref>
            <resource-ref>
                <res-ref-name>jdbc/DBDS</res-ref-name>
                <res-ref-type>javax.sql.DataSource</res-ref-type>
            </resource-ref>
            . . .
        </session>
    </enterprise-beans>
    . . .
</ejb-jar.xml>

Mapping External Reference to JNDI: <jeus-ejb-dd.xml>

<jeus-ejb-dd>
    . . .
    <beanlist>
        <jeus-bean>
            . . .
            <env>
                <name>minAmount</name>
                <type>java.lang.Integer</type>
                <value>100</value>
            </env>
            <ejb-ref>
                <jndi-info>
                    <ref-name>AccountEJB</ref-name>
                    <export-name>ACCEJB</export-name>
                </jndi-info>
            </ejb-ref>
            <res-ref>
                <jndi-info>
                    <ref-name>jdbc/DBDS</ref-name>
                    <export-name>ACCOUNTDB</export-name>
                </jndi-info>
            </res-ref>
            . . .
        </jeus-bean>
        . . .
    </beanlist>
    . . .
</jeus-ejb-dd>

2.4. Configuring the HTTP Invocation Environment

In order to set up HTTP invocation on a specific EJB module, you need to configure <invoke-http> in the <jeus-bean> element of jeus-ejb-dd.xml. If an EJB engine needs HTTP invocation, add the <invoke-http> tag to the ejb-engine in the jeus-ejb-dd.xml file (mentioned in EJB Engines). Settings in the domain.xml file will be applied to all modules, but if the DD of each module contains the <invoke-http> setting, the setting in DD file is used instead.

The following example configures the HTTP invoke environment properties in jeus-ejb-dd.xml.

Configuring HTTP Invocation: <jeus-ejb-dd.xml>

<jeus-ejb-dd>
    . . .
    <beanlist>
        <jeus-bean>
            . . .
            <invoke-http>
                <url>
                    /mycontext/RMIServletHandler
                </url>
                <http-port>
                    80
                </http-port>
            </invoke-http>
            . . .
        </jeus-bean>
    </beanlist>
    . . .
</jeus-ejb-dd>

The <invoke-http> tag has the following two child tags.

Tag	Description
<url>	URI of the RMI Handler Servlet (jeus.rmi.http.ServletHandler) that is called from the HTTP-RMI stub. Enter only the request path of the Servlet excluding the protocol, IP, and port. (required) Protocol and IP are assumed to be the same as HTTP and RMI runtime, respectively. This means the Web server and Web engine that received HTTP-RMI request should be on the same machine with the RMI runtime. This way, the RMI runtime address is known to the RMI stub. Web server port should be specified in the following <http-port> element.
<http-port>	Port to receive HTTP-RMI requests. The RMI Handler Servlet must be deployed and executed on the Web engine.

Tag

Description

<url>

URI of the RMI Handler Servlet (jeus.rmi.http.ServletHandler) that is called from the HTTP-RMI stub. Enter only the request path of the Servlet excluding the protocol, IP, and port. (required)

Protocol and IP are assumed to be the same as HTTP and RMI runtime, respectively. This means the Web server and Web engine that received HTTP-RMI request should be on the same machine with the RMI runtime. This way, the RMI runtime address is known to the RMI stub. Web server port should be specified in the following <http-port> element.

<http-port>

Port to receive HTTP-RMI requests. The RMI Handler Servlet must be deployed and executed on the Web engine.

The RMI handler servlet must be deployed to successfully execute an HTTP invoke. The class to implement the RMI handler servlet is jeus.rmi.http.ServletHandler. The jeus.rmi.http.ServletHandler must be deployed to the URL specified in the <invoke-http> element of the context. For more information about deployment, refer to JEUS Web Engine Guide.

2.5. Configuring EJB Security

This section describes how to configure security for EJB in JEUS. The security refers to certification and authorization.

JEUS EJB security configuration includes the following settings.

Role assignment of EJB modules
EJB run-as Identify setting

The actual JEUS user list used in EJB settings is defined in accounts.xml. For information about the settings, refer to JEUS Security Guide.

2.5.1. Security Settings

The following explains how to configure security settings for each case.

Configuring Role Assignment

The role assignment setting of EJB is mapping developer-defined role of the ejb-jar.xml file with principal and group name of the actual JEUS security domain. Configure this setting in the <role-permission> element inside the <module-info> element of the jeus-ejb-dd.xml file.

The following is an example of configuring a role in XML.

Configuring Role Assignment: <jeus-ejb-dd.xml>

<jeus-ejb-dd>
    <module-info>
        <role-permission>
            <role>manager</role>
            <principal>peter</principal>
        </role-permission>
    </module-info>
    <beanlist>
       . . .
    </beanlist>
    . . .
</jeus-ejb-dd>

The following are two required child tags:

Tag	Description
<role>	Specifies the logical role name defined in the EJB (through annotation or ejb-jar.xml file).
<principal>	Specifies actual user name defined in the accounts.xml file. A role name and user name pair defines the mapping between a developer-defined role and JEUS principal. A role can be mapped to multiple user names.

Tag

Description

<role>

Specifies the logical role name defined in the EJB (through annotation or ejb-jar.xml file).

Specifies actual user name defined in the accounts.xml file.

A role name and user name pair defines the mapping between a developer-defined role and JEUS principal. A role can be mapped to multiple user names.

Configuring Run-as Identify

Run-as identity setting provides the actual mapping of developer-defined role name in the <run-as> tag of the ejb-jar.xml file with the actual principal specified in the JEUS security domain configuration (e.g., in the accouts.xml file).

This principal, in general, uses a simple user name. This setting is configured in the <run-as-identity> tag, which is at the same level as the bean configuration in jeus-ejb-dd.xml.

The following is an example of XML setting for run-as identity.

Configuring Run-as Identify: <jeus-ejb-dd.xml>

<jeus-ejb-dd>
    . . .
    <beanlist>
        <jeus-bean>
            . . .
            <run-as-identity>
                <principal-name>peter</principal-name>
            </run-as-identity>
            . . .
        </jeus-bean>
        . . .
    </beanlist>
    . . .
</jeus-ejb-dd>

Tag	Description
<principal-name>	Specifies the user name to map with role in the <run-as> element of the ejb-jar.xml file. This user name should be specified in the accounts.xml file.

Tag

Description

<principal-name>

Specifies the user name to map with role in the <run-as> element of the ejb-jar.xml file. This user name should be specified in the accounts.xml file.

2.5.2. Security Setting Example

The following examples show how the role of role-permission and role of run-as are mapped to an actual JEUS user.

Some parts of Java classes and XML are taken from three configuration files (ejb-jar.xml, jeus-ejb-dd.xml, and accounts.xml). The identical parts in these files are highlighted in bold.

Security Setting: <CustomerBean.java>

@Stateless(name="CustomerEJB")
@RolesAllowed("CUSTOMER")
public class CustomerBean implementes Customer {
    ...
}

Security Setting: <EmployeeServiceBean.java>

@Stateful(name="EmployeeService")
@RunAs("ADMIN")
public class EmployeeServiceBean implements EmployService{
    ...
}

Security Setting: <ejb-jar.xml>

<?xml version="1.0"?>
<ejb-jar version="4.0" xmlns="https://jakarta.ee/xml/ns/jakartaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee
https://jakarta.ee/xml/ns/jakartaee/ejb-jar_4_0.xsd">
    <enterprise-beans>
        <session>
            <ejb-name>CustomerEJB</ejb-name>
            . . .
            <security-role-ref>
                <role-name>CUSTOMER</role-name>
            </security-role-ref>
            <security-identity>
                <use-caller-identity />
            </security-identity>
        </session>
        <session>
            <ejb-name>EmployeeService</ejb-name>
            . . .
            <security-identity>
                <run-as>
                    <role-name>ADMIN</role-name>
                </run-as>
            </security-identity>
        </session>
        . . .
    </enterprise-beans>
    <assembly-descriptor>
       <security-role>
           <role-name>CUSTOMER</role-name>
       </security-role>
       <method-permission>
           <role-name>CUSTOMER</role-name>
           <method>
               <ejb-name>CustomerEJB</ejb-name>
               <method-name>*</method-name>
               <method-params />
           </method>
       </method-permission>
        . . .
    </assembly-descriptor>
    . . .
</ejb-jar>

The previous example defines two session beans.

The first bean (CustomerEJB) has a security role connected to the CUSTOMER role.
The second session bean (EmployeeService) defines the <run-as> role as ADMIN. The roles CUSTOMER and ADMIN should be mapped to actual system Principals when EJB is deployed.

The following example shows how the roles of CUSTOMER and ADMIN are mapped to the actual system principal names (customer and peter, respectively).

Security Setting: <jeus-ejb-dd.xml>

<?xml version="1.0" encoding="UTF-8"?>
<jeus-ejb-dd xmlns="http://www.tmaxsoft.com/xml/ns/jeus">
    <module-info>
        . . .
        <role-permission>
            <principal>customer</principal>
            <role>CUSTOMER</role>
        </role-permission>
    </module-info>
    <beanlist>
        <jeus-bean>
            <ejb-name>EmployeeService</ejb-name>
            <run-as-identity>
                <principal-name>peter</principal-name>
            </run-as-identity>
        </jeus-bean>
        . . .
    </beanlist>
    . . .
</jeus-ejb-dd>

The following example shows how these users are configured in the accounts.xml file.

Security Setting: <accounts.xml>

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<accounts xmlns="http://www.tmaxsoft.com/xml/ns/jeus">
    <users>
        <user>
            <name>customer</ name>
            <password>{SHA}blSUPYpdjb8QDcq+ozfbIEZx5oY=</name>
            <group>test</group>
        </user>
       <user>
            <name>peter</ name>
            <password>{SHA}McbQlyhI3yiOG1HGTg8DQVWkyhg=</name>
            <group>test</group>
        </user>
    </users>
</accounts>

The previous example shows definition for the users, customer and peter. These users are connected to the roles, CUSTOMER and ADMIN, of the ejb-jar.xml file through the jeus-ejbdd.xml file.

3. Monitoring EJBs

JEUS does not provide a method to control individual EJBs included in the EJB module. However, you can monitor each bean by using the console tool.

In the console tool, information about each EJB, including bean name, export name, and status, can be displayed using the application-info command. The following example is based on the assumption that an EJB called 'countermod' has been deployed. For more information about the application-info command, refer to application-info.

As the result of the previous command, the name and export name of each bean registered to the EJB module are displayed.

[MASTER]domain1.adminServer>application-info -server server1 -id countermod -detail
General information about the EJB module [countermod].
==============================================================
+-------------+----------------------------------------------+
| Module Name |              Unique Module Name              |
+-------------+----------------------------------------------+
| countermod  | countermod                                   |
+-------------+----------------------------------------------+
==============================================================

Beans
================================================================================
+-----------+-------------------------+-------------------+--------------------+
| Bean Name |           Type          | Local Export Name | Remote Export Name |
+-----------+-------------------------+-------------------+--------------------+
| Count     | StatelessSessionBean    |                   | Count              |
+-----------+-------------------------+-------------------+--------------------+
================================================================================

The status of each bean in EJB module can be monitored with the following command.

[MASTER]domain1.adminServer>application-info -server server1 -id countermod -bean Count
Module name : countermod
Bean name : Count
================================================================================
+---------------+-----------+-------------------+--------------+---------------+
|      Name     |  (Count)  | WaterMark(High:Low| Bound(Upper:L| Time(Max:Min:T|
|               |           |       :Cur)       |    ower)     |     otal)     |
+---------------+-----------+-------------------+--------------+---------------+
| create        | times(0)  |                   |              |               |
+---------------+-----------+-------------------+--------------+---------------+
| comitted      | transactio|                   |              |               |
|               |n(0)       |                   |              |               |
+---------------+-----------+-------------------+--------------+---------------+
| total-remote-t|           |thread(100:100:100)|              |               |
|hread          |           |                   |              |               |
+---------------+-----------+-------------------+--------------+---------------+
| timed-rb      | transactio|                   |              |               |
|               |n(0)       |                   |              |               |
+---------------+-----------+-------------------+--------------+---------------+
| remove        | times(0)  |                   |              |               |
+---------------+-----------+-------------------+--------------+---------------+
| active-bean   |           | bean(0:0:0)       |              |               |
+---------------+-----------+-------------------+--------------+---------------+
| request       | request(0)|                   |              |               |
+---------------+-----------+-------------------+--------------+---------------+
| total-bean    |           | bean(0:0:0)       |              |               |
+---------------+-----------+-------------------+--------------+---------------+
| rolledback    | transactio|                   |              |               |
|               |n(0)       |                   |              |               |
+---------------+-----------+-------------------+--------------+---------------+
| active-thread |           | thread(0:0:0)     |              |               |
+---------------+-----------+-------------------+--------------+---------------+
| MethodReadyCou|           | bean(0:0:0)       |              |               |
|nt             |           |                   |              |               |
+---------------+-----------+-------------------+--------------+---------------+
================================================================================

4. Tuning EJBs

There are some settings that can be uniformly applied to all EJB types in order to enhance EJB operation performance (or to prevent system resources from being wasted):

Adjust the max value of TTP.
Configure beans after clustering beans from several EJB engines. Refer to EJB Clustering.
Set up an appropriate JDBC connection pool. For more information about the settings, refer to JEUS Server Guide.
For EJB 2.x, use the -fast option and the appcompiler to save the deployment time of EJB modules. Refer to EJB Modules for more information.

There are many tuning tips for each bean type besides the already mentioned basic optimization options. Therefore, look up the corresponding chapter for optimization and tuning method recommended for each EJB type.

4.1. Configuring Thread Ticket Pools

The TTP should be configured correctly for an EJB to exhibit the best performance. You can apply the following principles for this.

The larger the specified max pool size, the more TTs can be generated and more client requests can be processed. However, a large max pool size consumes more memory resources.
If the number of clients who request a service of a bean increases rapidly at a specific time, increase the pool size by subtracting the min pool size from the max pool size. This enables the new TTs to be created in batches.

TTP setting acts as a valve that controls the volume of accesses to a certain EJB.

The max pool size is the most important parameter in the thread ticket pool. Therefore, this value should be adjusted and tuned first to improve performance. Set this value to <thread-max>.