11) How does an enterprise bean that uses container-managed transactions obtain a JTA UserTransaction object?
 

It doesn't! By definition, container-managed transaction processing implies that the EJB container is responsible for transaction processing. The session bean has only limited control of transaction handling via the transaction attribute.

12) Is it possible for a stateless session bean to employ a JTA UserTransaction object?
 

Yes, but with restrictions. By definition, a stateless session bean has no state; hence, each method invocation must be independent. (The bean can be "swapped out" between method invocations.) Thus, a stateless session bean can obtain a UserTransaction object via the EJBContext using the getUserTransaction() method, but it must start and finish each transaction within the scope of a method invocation.

13) How do you configure a session bean for bean-managed transactions?
 

You must set transaction-type in the deployment descriptor.

14) How does an entity bean obtain a JTA UserTransaction object?
 

It doesn't. Entity beans do not employ JTA transactions; that is, entity beans always employ declarative, container-managed transaction demarcation. Entity beans, by definition, are somewhat tightly coupled (via the EJB container and server) to a datastore; hence, the EJB container is in the best position to manage transaction processing.

15) Is it necessary for an entity bean to protect itself against concurrent access from multiple transactions?
 

No. One of the motivations for using a distributed component architecture such as Enterprise JavaBeans is to free the business logic programmer from the burdens that arise in multiprogramming scenarios.

16) What are the constraints or drawbacks of container managed EJB's ?
 

CMP in beans depends a lot on the EJB vendor implementation and utilities. With some implementations container-managed entity beans can only by mapped to one table, while other implemenations offer Multiple table mappings to a single bean. The bottom line,It depends on the container provider being used.

17) Is entity data persisted at the end of a transaction or at any time?
 

Depends on what you mean by "persisted". Data that is part of a transaction like database rows are persisted depending on the success of the transaction. If the transaction manager determines that the transaction was successful or there were no problems during any of the steps invoved in it, the data is committed, or otherwise rolled back.

The container, on the other hand, invokes certain state transition lifecycle methods to conserve resources. This involves passivation and activation of the bean or instance swapping. This happens independent of the transaction since the client never interacts directly with the bean instance but with the server's implementation of the EJBObject. 

18) How do enterprise beans access native libraries?
 

In short, they don't.

The EJB 1.1 Specification, section 18.1.2 (Programming Restrictions) lists some things that enterprise beans cannot do. In particular:

·         The enterprise bean must not attempt to load a native library.

This function is reserved for the EJB Container. Allowing the enterprise bean to load native code would create a security hole.

19) How do I implement a logging system in my beans?
 

Using java.io is prohibited

Using the java.io package from within a bean is prohibited. The EJB 1.1 Specification, section 18.1.2 (Programming Restrictions) states the following:

ï‚·  An enterprise bean must not use the java.io package to attempt to access files and directories in the file system.

The file system APIs are not well-suited for business components to access data. Business components should use a resource manager API, such as JDBC API, to store data.

Alternative Solutions

To perform logging operations you must you a resource connection supported by the EJB programming model. EJB servers may support several resource connection options, which can be used to log events as shown below:

·         JDBC (javax.sql.DataSource) : Write log events in to a relational database.

·         URL (java.net.URL) : Write log events to a custom logging server or post them to a web server.

·         JavaMail (javax.mail.Session) : E-mail log events to a special account

·         JMS (javax.jms.QueueConnectionFactory | javax.jms.TopicConnectionFactory) : Send the log events as messages.

20) What is a container?
 

Enterprise beans are software components that run in a special environment called an EJB container. The container hosts and manages an enterprise bean in the same manner that a Java WebServer hosts a Servlet or an HTML browser hosts a Java applet. An enterprise bean cannot function outside of an EJB container. The EJB container manages every aspect of an enterprise bean at run time including remote access to the bean, security, persistence, transactions, concurrency, and access to and pooling of resources.

The container isolates the enterprise bean from direct access by client applications. When a client application invokes a remote method on an enterprise bean, the container first intercepts the invocation to ensure persistence, transactions, and security are applied properly to every operation a client performs on the bean. The container manages security, transactions, and persistence automatically for the bean, so the bean developer doesn't have to write this type of logic into the bean code itself. The enterprise bean can focus on encapsulating business rules, while the container takes care of everything else.

Containers will manage many beans simultaneously in the same fashion that a Java WebServer manages many Servlets. To reduce memory consumption and processing, containers pool resources and manage the lifecycles of all the beans very carefully. When a bean is not being used a container will place it in a pool to be reused by another client, or possibly evict it from memory and only bring it back when its needed. Because client applications don't have direct access to the beans -- the container lies between the client and bean -- the client application is completely unaware of the containers resource management activities. A bean that is not in use, for example, might be evicted from memory on the server, while its remote reference on the client remains intact. When the client invokes a method on the remote reference, the container simply re-incarnates the bean to service the request. The client application is unaware of the entire process.

An enterprise bean depends on the container for everything it needs. If an enterprise bean needs to access a JDBC connection or another enterprise bean, it does so through the container; if an enterprise bean needs to access the identity of its caller, obtain a reference to itself, or access properties it does so through the container. The enterprise bean interacts with its container through one of three mechanisms: callback methods, the EJBContext interface, or JNDI.

Callback Methods: Every bean implements a subtype of the EnterpriseBean interface which defines several methods, called callback methods. Each callback method alerts the bean of a different event in its lifecycle and the container will invoke these methods to notify the bean when it's about to pool the bean, persist its state to the database, end a transaction, remove the bean from memory, etc. The callback methods give the bean a chance to do some housework immediately before or after some event. Callback methods are discussed in more detail in other sections.

EJBContext: Every bean obtains an EJBContext object, which is a reference directly to the container. The EJBContext interface provides methods for interacting with the container so that that bean can request information about its environment like the identity of its client, the status of a transaction, or to obtain remote references to itself.

JNDI: Java Naming and Directory Interface is a Java extension API for accessing naming systems like LDAP, NetWare, file systems, etc. Every bean automatically has access to a special naming system called the Environment Naming Context (ENC). The ENC is managed by the container and accessed by beans using JNDI. The JNDI ENC allows a bean to access resources like JDBC connections, other enterprise beans, and properties specific to that bean.

The EJB specification defines a bean-container contract, which includes the mechanisms (callbacks, EJBContext, JNDI ENC) described above as well as a strict set of rules that describe how enterprise beans and their containers will behave at runtime, how security access is checked, transactions are managed, persistence is applied, etc. The bean-container contract is designed to make enterprise beans portable between EJB containers so that enterprise beans can be developed once then run in any EJB container. Vendors like BEA, IBM, and Gemstone sell application servers that include EJB containers. Ideally, any enterprise bean that conforms to the specification should be able to run in any conformant EJB container.

Portability is central to the value that EJB brings to the table. Portability ensures that a bean developed for one container can be migrated to another if another brand offers more performance, features, or savings. Portability also means that the bean developer's skills can be leveraged across several EJB container brands, providing organizations and developers with better opportunities.

In addition to portability, the simplicity of the EJB programming model makes EJB valuable. Because the container takes care of managing complex tasks like security, transactions, persistence, concurrency and resource management the bean developer is free to focus attention on business rules and a very simple programming model. A simple programming model means that beans can be developed faster without requiring a Ph.D. in distributed objects, transactions and other enterprise systems. EJB brings transaction processing and distributed objects development into the mainstream.