What is passivation and activation?
Passivation and activation are two phases of a resource management technique that reduces the number of bean instances needed to service all clients. Passivation is the process of disassociating a bean instance from its EJB object so that the instance can be reused or evicted to conserve memory. Activation is the process of associating a bean instance with an EJB object so that it can service a request. Beans are passivated when there is a lull in their use and activated when the EJB object receives a client request.
The java.ejb.SessionBean and javax.ejb.EntityBean interface include two callback methods that notify a bean instance when it is about to passivated or activated. The ejbPassivate( ) method notifies a bean that it is about to passivated; the ejbActivate( ) method notifies a bean that it is about to activated.
The mechanisms employed in passivation and activation change depending on the bean type. Stateful beans are usually evicted, while entity beans and stateless beans are pooled. A more detailed account of how different bean types passivated and activated is found under the FAQs for that type.
Do JTS implementations support nested transactions?
A JTS transaction manager must support flat transactions; support of nested transactions is optional. If a client begins a transaction, and within that transaction begins another transaction, the latter operation will throw a NotSupportedException if the JTS implementation does not support nested transactions.
Keep in mind that even if the JTS implementation supports nested transactions, this transaction manager-level support does not guarantee support for nested transactions in an application. For example, the EJB 1.1 specification does not support nested transactions.
Why would a client application use JTA transactions?
One possible example would be a scenario in which a client needs to employ two (or more) session beans, where each session bean is deployed on a different EJB server and each bean performs operations against external resources (for example, a database) and/or is managing one or more entity beans. In this scenario, the client's logic could required an all-or-nothing guarantee for the operations performed by the session beans; hence, the session bean usage could be bundled together with a JTA UserTransaction object.
In the previous scenario, however, the client application developer should address the question of whether or not it would be better to encapsulate these operations in yet another session bean, and allow the session bean to handle the transactions via the EJB container. In general, lightweight clients are easier to maintain than heavyweight clients. Also, EJB environments are ideally suited for transaction management.
How does a session bean obtain a JTA UserTransaction object?
If it's necessary to engage in explicit transaction management, a session bean can be designed for bean-managed transactions and obtain a UserTransaction object via the EJBContext using the getUserTransaction() method. (It may also use JNDI directly, but it's simpler to use this convenience method.)
Why would a session bean use bean-managed transactions?
In some situations, it's necessary for a (stateful) session bean to selectively control which methods participate in transactions, and then take over the bundling of operations that form a logical unit of work.
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.
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.
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.
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.
How do you implement callbacks in EJB?
If your client is an EJB, it can pass a reference to itself to the method of the bean that it is calling. The EJB can then call methods directly on that interface.
If your client is a Java client, your client requires some sort of object that will "listen" for call-backs. This could be either a CORBA or RMI object. Again, you could pass references to these objects to the EJB, which could then invoke methods on the references.
How is the passivation of Entity beans Managed?
The passivation of Entity beans is managed by the container. To passivate an instance, the container first invokes the ejbStore() method for synchronizing the database with the bean instance, then the container invokes the ejbPassivate() method. It will then return the bean instance back to the pooled state. (Every bean has an instance pool.)
There are two ways for transitioning an entity bean from the ready to the pooled state, by using the ejbPassivate() or ejbRemove() method. The container uses ejbPassivate() to disassociate the bean instance from the entity object identity, and uses ejbRemove() to remove the entity object.
When the instance is put back into the pool, it is no longer associated with an entity object identity. The container can now assign the instance to any entity object within the same entity bean home.
A bean instance in the pool can be removed by using unsetEntityContext().
A more thorough discussion can be found in the EJB 1.1 specification by Sun.
What is an EJB Context?
EJBContext is an interface that is implemented by the container, and it is also a part of the bean-container contract. Entity beans use a subclass of EJBContext called EntityContext. Session beans use a subclass called SessionContext. These EJBContext objects provide the bean class with information about its container, the client using the bean and the bean itself. They also provide other functions. See the API docs and the spec for more details.
What is the difference between a Server, a Container, and a Connector?
To keep things (very) simple:
An EJB server is an application, usually a product such as BEA WebLogic, that provides (or should provide) for concurrent client connections and manages system resources such as threads, processes, memory, database connections, network connections, etc.
An EJB container runs inside (or within) an EJB server, and provides deployed EJB beans with transaction and security management, etc. The EJB container insulates an EJB bean from the specifics of an underlying EJB server by providing a simple, standard API between the EJB bean and its container.
(Note: The EJB 1.1 specification makes it clear that it does not architect the interface between the EJB container and EJB server, which it says it left up to the vendor on how to split the implementation of the required functionality between the two. Thus there is no clear distinction between server and container.)
A Connector provides the ability for any Enterprise Information System (EIS) to plug into any EJB server which supports the Connector architecture. See http://java.sun.com/j2ee/connector/ for more indepth information on Connectors.
What restrictions are imposed on an EJB? That is, what can't an EJB do?
From the spec:
· An enterprise Bean must not use read/write static fields. Using read-only static fields is allowed. Therefore, it is recommended that all static fields in the enterprise bean class be declared as final.
· An enterprise Bean must not use thread synchronization primitives to synchronize execution of multiple instances.
· An enterprise Bean must not use the AWT functionality to attempt to output information to a display, or to input information from a keyboard.
· An enterprise bean must not use the java.io package to attempt to access files and directories in the file system.
· An enterprise bean must not attempt to listen on a socket, accept connections on a socket, or use a socket for multicast.
· The enterprise bean must not attempt to query a class to obtain information about the declared members that are not otherwise accessible to the enterprise bean because of the security rules of the Java language. The enterprise bean must not attempt to use the Reflection API to access information that the security rules of the Java programming language make unavailable.
· The enterprise bean must not attempt to create a class loader; obtain the current class loader; set the context class loader; set security manager; create a new security manager; stop the JVM; or change the input, output, and error streams.
· The enterprise bean must not attempt to set the socket factory used by ServerSocket, Socket, or the stream handler factory used by URL.
· The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread; or to change a thread's priority or name. The enterprise bean must not attempt to manage thread groups.
· The enterprise bean must not attempt to directly read or write a file descriptor.
· The enterprise bean must not attempt to obtain the security policy information for a particular code source.
· The enterprise bean must not attempt to load a native library.
· The enterprise bean must not attempt to gain access to packages and classes that the usual rules of the Java programming language make unavailable to the enterprise bean.
· The enterprise bean must not attempt to define a class in a package.
· The enterprise bean must not attempt to access or modify the security configuration objects (Policy, Security, Provider, Signer, and Identity).
· The enterprise bean must not attempt to use the subclass and object substitution features of the Java Serialization Protocol.
The enterprise bean must not attempt to pass this as an argument or method result. The enterprise bean must pass the result of SessionContext.getEJBObject() or EntityContext. getEJBObject() instead.