Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Enterprise JavaBeans™ Specification, Version 2.0 - Sun Microsystems.pdf
Скачиваний:
14
Добавлен:
24.05.2014
Размер:
2.71 Mб
Скачать

Sun Microsystems Inc

Client-demarcated transactions

Enterprise JavaBeans 2.0, Public Draft

Frequently asked questions

Appendix D Frequently asked questions

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

D.1 Client-demarcated transactions

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

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();

...

509

5/31/00

Sun Microsystems Inc.

Frequently asked questions

Enterprise JavaBeans 2.0, Public Draft

Container managed persistence

D.2 Container managed persistence

EJB 2.0 supports both field-based and method-based container managed persistence. The EJB 2.0 specification recommends that the new EJB 2.0 mechanism be used for new work because of the added functionality that it provides. Before making a decision, however, the Bean Provider should evaluate the advantages and limitations of both mechanisms and choose the one that best supports his or her needs.

The use of both EJB 2.0 method-based and EJB1.1 field-based container managed persistence entity beans can be combined in the same EJB 2.0 application. The beans that are written to the EJB1.1 container managed persistence API, however, must be indicated as such in the EJB 2.0 deployment descriptor.

EJB 2.0 containers must support the EJB 1.1 mechanism for container managed persistence. EJB 1.1 entity beans and deployment descriptors are supported by EJB 2.0. The EJB 1.1 container managed persistence mechanism has not been deprecated.

D.3 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 language support for inheritance as follows:

Interface inheritance. It is possible to use the Java 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.

D.4 Entities and relationships

The current EJB architecture does not specify how an Entity bean with bean managed persistence or an EJB 1.1 Entity Bean with container managed persistence 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 EJB 1.1 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.

5/31/00

510

Sun Microsystems Inc

How to obtain database connections

Enterprise JavaBeans 2.0, Public Draft

Frequently asked questions

Home name and object’s primary key.

Home object reference and object’s primary key.

Object’s handle.

D.5 How to obtain database connections

Section 19.4 specifies how an enterprise bean should obtain connections to resources such as JDBC connections. The connection acquisition protocol uses resource 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();

...

}

}

D.6 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.

D.7 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.

511

5/31/00

Sun Microsystems Inc.

Frequently asked questions

Enterprise JavaBeans 2.0, Public Draft Copying of parameters required for EJB calls

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.

5/31/00

512