Sun Microsystem Inc

Appendix B Frequently asked questions

This Appendix provides the answers to a number of frequently asked questions.

B.1 Client-demarcated transactions

The EJB 1.0 specification did not explain how a client other than another enterprise bean can obtain a the javax.transaction.UserTransaction interface.

The Java2, Enterprise Edition specification [10] defines how a client can obtain the javax.transaction.UserTransaction interface using JNDI.

Sun Microsystems Inc.

The following is an example of how a Java application can obtain the javax.transaction.UserTransaction interface.

...

Context ctx = new InitialContext(); UserTransaction utx =

(UserTransaction)ctx.lookup(“java:comp/UserTransaction”);

//

// Perform calls to enterprise beans in a transaction.

//

utx.begin();

... call one or more enterprise beans utx.commit();

...

B.2 Inheritance

The current EJB specification does not specify the concept of component inheritance. There are complex issues that would have to be addressed in order to define component inheritance (for example, the issue of how the primary key of the derived class relates to the primary key of the parent class, and how component inheritance affects the parent component’s persistence).

However, the Bean Provider can take advantage of the Java programming language support for inheritance as follows:

•Interface inheritance. It is possible to use the Java programming language interface inheritance mechanism for inheritance of the home and remote interfaces. A component may derive its home and remote interfaces from some “parent” home and remote interfaces; the component then can be used anywhere where a component with the parent interfaces is expected. This is a Java language feature, and its use is transparent to the EJB Container.

•Implementation class inheritance. It is possible to take advantage of the Java class implementation inheritance mechanism for the enterprise bean class. For example, the class CheckingAccountBean class can extend the AccountBean class to inherit the implementation of the business methods.

Sun Microsystem Inc

B.3 Entities and relationships

The current EJB architecture does not specify how one Entity bean should store an object reference of another Entity bean. The desirable strategy is application-dependent. The enterprise bean (if the bean uses bean-managed persistence) or the Container (if the bean uses container-managed persistence) can use any of the following strategies for maintaining persistently a relationship between entities (the list is not inclusive of all possible strategies):

•Object’s primary key. This is applicable if the target object’s Home is known and fixed.

•Home name and object’s primary key.

•Home object reference and object’s primary key.

•Object’s handle.

B.4 Finder methods for entities with container-managed persistence

The EJB specification does not provide a formal mechanism for the Bean Provider of a bean with con- tainer-managed persistence to specify the criteria for the finder methods.

The current mechanism is that Bean Provider describes the finders in a description of the Entity Bean. The current EJB specification does not provide any syntax for describing the finders.

We plan to address this issue in a future release of the specification.

B.5 JDK 1.1 or Java 2

Chapter 18 describes the issue of using JDK 1.1 versus Java 2 in detail.

In summary, the Bean Provider can produce enterprise beans that will run in both JDK 1.1 and Java 2 platform based Containers. The Container Provider can use either JDK 1.1 or Java 2 platform as the basis for the implementation of the Container.

B.6 javax.transaction.UserTransaction versus javax.jts.UserTransaction

The correct spelling is javax.transaction.UserTransaction.

The use of javax.jts.UserTransaction is deprecated in EJB 1.1.

Sun Microsystems Inc.

B.7 How to obtain database connections

Section 14.4 specifies how an enterprise bean should obtain connections to resources such as JDBC API connections. The connection acquisition protocol uses resource manager connection factory references that are part of the enterprise bean’s environment.

The following is an example of how an enterprise bean obtains a JDBC connection:

public class EmployeeServiceBean implements SessionBean { EJBContext ejbContext;

public void changePhoneNumber(...) {

...

//obtain the initial JNDI context Context initCtx = new InitialContext();

//perform JNDI lookup to obtain resource manager connection

//factory

javax.sql.DataSource ds = (javax.sql.DataSource) initCtx.lookup("java:comp/env/jdbc/EmployeeAppDB");

//Invoke factory to obtain a connection. The security

//principal is not given, and therefore

//it will be configured by the Deployer. java.sql.Connection con = ds.getConnection();

...

}

}

B.8 Session beans and primary key

The EJB 1.1 specification specifies the Container’s behavior for the cases when a client attempts to access the primary key of a session object. In summary, the Container must throw an exception on a client’s attempt to access the primary key of a session object.

B.9 Copying of parameters required for EJB calls within the same JVM

The enterprise bean’s home and remote interfaces are remote interface in the Java RMI sense. The Container must ensure the Java RMI argument passing semantics. Non-remote objects must be passed by value.

Specifically, the EJB Container is not allowed to pass local objects by reference on inter-enterprise bean invocations when the calling and called enterprise beans are collocated in the same JVM. Doing so could result in the multiple beans sharing the state of a Java object, which would break the enterprise bean’s semantics.