Showing posts with label EJB Interview Questions with Answers. Show all posts
Showing posts with label EJB Interview Questions with Answers. Show all posts

Top 30 EJB Interview Questions and Answers

What are the differences between the Java Transaction API (JTA) and Java Transaction Service (JTS) ?

Java Transaction API (JTA)
JTA specifies the interfaces between a transaction manager and the other parties involved in a distributed transaction processing system.
  • application programs
  • resource managers
  • application server
Java Transaction Service (JTS)
  • Java binding of the CORBA Object Transaction Service (OTS) 1.1 specification
  • Provides transaction interoperability using the standard IIOP protocol for transaction propagation between servers
  • Intended for vendors who implement transaction processing infrastructure for enterprise middleware
    • may be used by an EJB Server vendor as the underlying transaction manager

When we can use TxDataSource instead of Datasource?

If your application  (or) environment meets the following criteria you should use
  • Uses JTA
  • Uses EJB container in web logic server to manage transactions.
  • Includes multiple database updates with single transaction.
  • Access multiple resources, such as database & JMS during transactions.
  • Use same connection pool on multiple servers.

Explain Context, InitialContext, SessionContext and EntityContext ?

javax.naming.Context is an interface that provides methods for binding a name to an object. It's much like the RMI Naming.bind() method.

javax.naming.InitialContext is a Context and provides implementation for methods available in the Context interface.

Where as SessionContext is an EJBContext object that is provided by the EJB container to a SessionBean in order for the SessionBean to access the information and/or services or the container.

There is EntityContext which is also and EJBContext object that'll be provided to an EntityBean for the purpose of the EntityBean accessing the container details. In general, the EJBContext (SessionContext and EntityContext), AppletContext and ServletContext help the corresponding Java objects in knowing about its 'context'  and to access particular information and/or service. Where as, the javax.naming.

What are the Container-managed transactions ?

NotSupported : 
  • container invokes enterprise Bean method with an unspecified transaction context.
Required : 
  • container invokes enterprise Bean method with a valid transaction context.
Supports :
  • If the client calls with a transaction context, same as Required.
  • If the client calls without a transaction context, same as NotSupported.
RequiresNew : 
  • container invokes enterprise Bean method with a new transaction context.
Mandatory : 
  • container invokes enterprise Bean method with the client’s transaction context.
Never : 
  • container invokes an enterprise Bean method without a transaction context.
  • client is required to call without a transaction context.

Explain ACID Properties?

Atomicity: In a transaction involving two or more discrete pieces of information, either all of the pieces are committed or none are.

Consistency: A transaction either creates a new and valid state of data, or, if any failure occurs, returns all data to its state before the transaction was started.

Isolation: A transaction in process and not yet committed must remain isolated from any other transaction.

Durability: Committed data is saved by the system such that, even in the event of a failure and system restart, the data is available in its correct state.

What are the Session Bean CallBack methods ?

public interface javax.ejb.SessionBean extends javax.ejb.EnterpriseBean
{
    public abstract void ejbActivate();
    public abstract void ejbCreate();
    public abstract void ejbPassivate();
    public abstract void ejbRemove();
    public abstract void setSessionContext(SessionContext ctx);
}

  • SessionContext a S.C is your beans gateway to interact with the container, S.C query the container about your current transactional state, your security state.
  • The ejbCreate() methods is part of the bean's lifecycle, so, the compiler will not return an error because there is no ejbCreate() method.
  • ejbPassivate( ) a If too many beans are instantiated, the container can passivate some of them .ie write the bean to some temp storage. The container should release all resources held by the bean. Just before passivating, the container calls the ejbPassivate() method. So release all resources here, i.e. close socket connections..etc.
  • ejbActivate( ) a When a passiavted bean is called, its said to be activated. The container then calls the ejbActivate() method. Acquire all the required resources for the bean in this method. ie get socket connection
  • ejbRemove() a container wants to remove your bean instance it will call this method.

Can i call remove() on a Stateless Session bean?

Yes, The life of a Stateless Session bean for a client is just till the execution of the method that the client would have called on the bean…after the execution of that method if the client calls another method, then a different bean is taken from the pool. So the container very well knows that a bean has finished its life for a client and can put it back in the pool.

Can a Session Bean be defined without ejbCreate() method?

  • The ejbCreate() methods is part of the bean's lifecycle, so, the compiler will not return an error because there is no ejbCreate() method.
  • The home interface of a Stateless Session Bean must have a single create() method with no arguments, while the session bean class must contain exactly one ejbCreate() method, also without arguments.
  • Stateful Session Beans can have arguments (more than one create method).
  •  Stateful beans can contain multiple ejbCreate() as long as they match with the home interface definition

What are the differences between the Stateful session bean and Stateless session bean ?

Stateless Session Bean
Stateful Session Bean
Stateless session bean these are single request business process is one that does not require state to be maintained across method invocation. Stateless session bean cannot hold the state.
Statefull session bean is a bean that is designed to service business process that span multiple methods request/transaction, S.S.B can retain their state on the behalf of individual client.
There should be one and only one create method that to without any argument in the home interface.
There can be one or more create methods with or without arguments in the Home Interface.
Stateless session bean instance can be pooled. Therefore “n” number of beans can cater to n+1 number of clients.
Statefull session bean do not have pooling concept. Stateful bean will be given individual copy for every user.
Stateless bean will not be destroyed after client has gone.
Stateful bean will be destroyed once the client has gone (or after session time out)
If the business last only for a single method call, S.S.B are suitable
If the business process spans multiple invocations there by requiring a conversational then S.S.B will be ideal choice.
Stateless session bean cannot have instance variable
Stateful session bean will have instance variable and state is maintained in these instance variables
EjbRemove() method does not destroy the bean , it remains in the pooled state.
Stateful bean can be destroyed by calling the ejbRemove() method

How do Stateful Session beans maintain consistency across transaction updates?

Stateful Session bean maintain data consistency by updating their fields each time a transaction is committed. To keep informed of changes in transation status, a Stateful Session bean implements the SessionSynchronization interface. Container then calls methods of this interface as it initiates and completes transactions involving the bean.

What are difference between the Statefull Session and Entity Bean?

Both Statefull Session Bean  and  Entity Bean undergo passivation and activation. The  Entity Bean have a separate ejbStore() callback for saving state during passivation and a separate ejbLoad() callback for loading state during activation. We do not need these callbacks for Statefull Session Bean because the container is simply uses object serialization to persist Statefull Session Bean fields.

When we can choose Entity Bean ?


When the bean represents a business entity, not a procedure. we should use an entity bean. Also when the bean’s state must be persistent we should use an entity bean. If the bean instance terminates or if the J2EE server is shut down, the bean’s state still exists in persistent storage (a database).

What is Message driven bean and it's life cycle?

Message driven bean process messages asynchronously are deliver via JMS. M.D.B’s are stateless, server side, transaction aware components used for asynchronous JMS messages. It acts as a JMS message listener which JMS messages, the messages may be sent by any J2ee component, an application client, another enterprise bean, or by a JMS application.
     When EJB application server starts it parse the D.D and then loads and initializes declared beans. In case of M.D.B container establish a connection with the message provide(MOM server), client access message beans through the beans JMS interface (java.JMS.messageListerner) which exposes a single method.
 
Message driven bean’s life cycle
  • EJB container creates a pool of message-driven bean instances
  • For each instance, the EJB container instantiates the bean :
    • It calls the setMessageDrivenContext
    • It calls the instance's ejbCreate
  • Like a stateless session bean,it’s never passivated, It has only two states:
    • Nonexistent 
    • Ready to receive messages.
  • is only a bean class – no interfaces 
  • While in the ready state :
    • EJB container may call onMessage
    • EJB container may call the ejbRemove
 

What is an Entity Bean? Explain it's life cycle?


An entity bean represents a business object in a persistent storage mechanism. An entity bean typically represents a table in a relational database and each instance represents a row in the table. Entity bean differs from session bean by: persistence, shared access, relationship and primary key.


Entity Bean Life Cycle
  • The EJB container :
    • Creates the instance
    • Calls the setEntityContext
  • The entity bean moves to a pool of available instances
  • While in the pool :
    • Instance is not associated with any particular object identity
    • All instances in the pool are identical
    • EJB container may assign an identity to an instance when moving it to the ready stage invoking the ejbActivate method.
    • A client may invoke the create method
    • EJB container calls ejbCreate and ejbPostCreate
    • EJB container may remove the instance invoking unsetEntityContext
    • Same bean instance (row) shared by all client
     
  • While in the ready state : 
    • A client may invoke entity bean's business methods
    • A client may invoke the remove method
    • EJB container calls the ejbRemove method
    • EJB container may invoke the ejbPassivate method

When to use a stateless session bean?

The bean’s state has no data for a specific client. In a single method invocation, the bean performs a generic task for all clients. For example, you might use a stateless session bean to send an email that confirms an online order. The bean fetches from a database a set of read-only data that is often used by clients. Such a bean, for example, could retrieve the table rows that represent the products that are on sale this month. Under all the above circumstance we can use a stateless session bean.

When to use Stateful session bean?


The bean’s state represents the interaction between the bean and a specific client. The bean needs to hold information about the client across method invocations. The bean mediates between the client and the other components of the application, presenting a simplified view to the client. Under all the above circumstances we can use a stateful session bean.

Difference between the Stateless session bean and Stateful session bean?

  • Stateless session beans do not maintain state associated with any client. Each stateless session bean can server multiple clients.
  • Stateful session beans maintain the state associated with a client. Each stateful session bean serves exactly one client.
  • Stateless session beans are intended to be simple and lightweight; that is, they are easy to develop with low runtime resource requirements on the server. If required, any state is maintained by the client, and thereby makes the server highly scalable. Because no state is maintained in this enterprise bean type, stateless session beans aren't tied to any specific client. Therefore, any available instance of a stateless session bean can be used to service another client.
  • The container creates an implicit identity for a stateful session bean to manage its passivation and activation phases. On the other hand, the container doesn't create any identity for a stateless session bean.
  • The number of stateful session beans is equal to the number of active clients, whereas a small number of stateless session beans can be used to satisfy a large number of clients.
  • Stateful session beans provide easy and transparent state management on the server side. Because state is maintained in this enterprise bean type, the application server manages client-bean pairs.  Any conversational state-related data in the object's variables doesn't survive a server shutdown or crash, although a vendor could provide an enhanced implementation to make shutdowns and crashes transparent to the client by maintaining the enterprise bean's state.

What is stateless session bean ? Explain Life Cycle?

Stateless session beans are of equal value for all instances of the bean. This means the container can assign any bean to any client, making it very scalable.
A stateless session bean is an enterprise bean that provides a stateless service to the client. 
Conceptually, the business methods on a stateless session bean are similar to procedural applications or static methods; there is no instance state, so all the data needed to execute the method is provided by the method arguments. The stateless session bean is an EJB component that implements the javax.ejb.SessionBean interface and is deployed with the declarative attribute “stateless”. 
Stateless session beans are called “stateless” because they do not maintain conversational state specific to a client session. In other words, the instance fields in a stateless session bean do not maintain data relative to a client session. This makes stateless session beans very lightweight and fast, but also limits their behavior. Typically an application requires less number of stateless beans compared to stateful beans.
 Stateless Session Bean Life Cycle
Stateless session beans have a simple lifecycle and the Container performs the following:
  • Creates bean instances using the default constructor as needed
  • Injects resources such as database connections
  • Puts instances into a managed pool
  • Pulls an idle bean from the pool when an invocation request is received from the client
  • Executes the requested business method invoked through the business interface by the client
  • When the business method finishes executing, pushes the bean back into the "method-ready" pool
  • As needed retires (destroys) beans from the pool based on pool sizes  

What is Stateful session bean? Explain it's life cycle?

Stateful session bean maintain the state of the conversation between the client and itself. When the client invokes a method on the bean the instance variables of the bean may contain a state but only for the duration of the invocation.
 
A stateful session bean is an enterprise bean (EJB component) that acts as a server-side extension of the client that uses it. The stateful session bean is created by a client and will work for only that client until the client connection is dropped or the bean is explicitly removed. 
 
The stateful session bean is EJB component that implements the javax.ejb.SessionBean interface and is deployed with the declarative attribute “stateful”. 
 
Stateful session beans are called “stateful” because they maintain a conversational state with the client. In other words, they have state or instance fields that can be initialized and changed by the client with each method invocation. The bean can use the conversational state as it process business methods invoked by the client.
 
Stateful session bean Life Cycle:
 

Stateful session beans
have a more complex lifecycle and the Container performs the following:
  • Always creates new bean instances using the default constructor whenever a new client session is started
  • Injects resources
  • Stores the instance in memory
  • Executes the requested business method invoked through the business interface by the client
  • Waits for and executes subsequent client requests
  • If idle for a period of time, container passivates the instance, normally moved out of memory onto disk (serialize the entire bean instance)
  • If the client invokes a passivated bean, it is actived (brought back from disk to memory)
  • If a method with the @Remove is invoked the bean is destroyed after the method completes

 


Enter your email address to get our daily JOBS & INTERVIEW FAQ's Straight to your Inbox.

Make sure to activate your subscription by clicking on the activation link sent to your email