Java Interview Questions -Part 8

Question Is method overloading allowed in EJB? (EJB)

Answer Yes you can overload methods



Question Should synchronization primitives be used on bean methods? (EJB)

Answer No. The EJB specification specifically states that the enterprise bean is not allowed to use thread primitives. The container is responsible for managing concurrent access to beans at runtime



Question Question Are we allowed to change the transaction isolation property in middle of a transaction? (EJB)

Answer No. You cannot change the transaction isolation level in the middle of transaction.



Question Question For Entity Beans, What happens to an instance field not mapped to any persistent storage,when the bean is passivated? (EJB)

Answer The specification infers that the container never serializes an instance of an Entity bean (unlike stateful session beans). Thus passivation simply involves moving the bean from the "ready" to the "pooled" bin. So what happens to the contents of an instance variable is controlled by the programmer. Remember that when an entity bean is passivated the instance gets logically disassociated from it's remote object.

Be careful here, as the functionality of passivation/activation for Stateless Session, Stateful Session and Entity beans is completely different. For entity beans the ejbPassivate method notifies the entity bean that it is being disassociated with a particular entity prior to reuse or for dereferenc.



Question Question What is a Message Driven Bean, What functions does a message driven bean have and how do they work in collaboration with JMS? (EJB)

Answer Message driven beans are the latest addition to the family of component bean types defined by the EJB specification. The original bean types include session beans, which contain business logic and maintain a state associated with client sessions, and entity beans, which map objects to persistent data.

Message driven beans will provide asynchrony to EJB based applications by acting as JMS message consumers. A message bean is associated with a JMS topic or queue and receives JMS messages sent by EJB clients or other beans.

Unlike entity beans and session beans, message beans do not have home or remote interfaces. Instead, message driven beans are instantiated by the container as required. Like stateless session beans, message beans maintain no client-specific state, allowing the container to optimally manage a pool of message-bean instances.

Clients send JMS messages to message beans in exactly the same manner as they would send messages to any other JMS destination. This similarity is a fundamental design goal of the JMS capabilities of the new specification.

To receive JMS messages, message driven beans implement the javax.jms.MessageListener interface, which defines a single "onMessage()" method.

When a message arrives, the container ensures that a message bean corresponding to the message topic/queue exists (instantiating it if necessary), and calls its onMessage method passing the client's message as the single argument. The message bean's implementation of this method contains the business logic required to process the message.

Note that session beans and entity beans are not allowed to function as message beans.

Question Does RMI-IIOP support code downloading for Java objects sent by value across an IIOP connection in the same way as RMI does across a JRMP connection? (RMI)

Answer Yes. The JDK 1.2 support the dynamic class loading.



Question The EJB container implements the EJBHome and EJBObject classes. For every request from a unique client, does the container create a separate instance of the generated EJBHome and EJBObject classes? (EJB)

Answer The EJB container maintains an instance pool. The container uses these instances for the EJB Home reference irrespective of the client request. while refering the EJB Object classes the container creates a separate instance for each client request.

Another Answer

The instance pool maintainence is up to the implementation of the container. If the container provides one, it is available otherwise it is not mandatory for the provider to implement it. Having said that, yes most of the container providers implement the pooling functionality to increase the performance of the app server. How it is implemented, it is again up to the implementer.



Question What is the advantage of puttting an Entity Bean instance from the "Ready State" to "Pooled state"? (EJB)

Answer The idea of the "Pooled State" is to allow a container to maintain a pool of entity beans that has been created, but has not been yet "synchronized" or assigned to an EJBObject. This mean that the instances do represent entity beans, but they can be used only for serving Home methods (create or findBy), since those methods do not relay on the specific values of the bean. All these instances are, in fact, exactly the same, so, they do not have meaningful state. Jon Thorarinsson has also added: It can be looked at it this way:

If no client is using an entity bean of a particular type there is no need for cachig it (the data is persisted in the database).

Therefore, in such cases, the container will, after some time, move the entity bean from the "Ready State" to the "Pooled state" to save memory.

Then, to save additional memory, the container may begin moving entity beans from the "Pooled State" to the "Does Not Exist State", because even though the bean's cache has been cleared, the bean still takes up some memory just being in the "Pooled State".