EJB Interview Questions

Does RMI-IIOP support dynamic downloading of classes?

No, RMI-IIOP doesn’t support dynamic downloading of the classes as it is done with CORBA in DII (Dynamic Interface Invocation).Actually RMI-IIOP combines the usability of Java Remote Method Invocation (RMI) with the interoperability of the Internet Inter-ORB Protocol (IIOP).So in order to attain this interoperability between RMI and CORBA,some of the features that are supported by RMI but not CORBA and vice versa are eliminated from the RMI-IIOP specification.Does EJB 1.1 support mandate the support for RMI-IIOP ?

What is the meaning of the client API must support the Java RMI-IIOP programming model for portability, but the underlying protocol can be anything ?

EJB1.1 does mandate the support of RMI-IIOP. There are 2 types of implementations that an EJB Server might provide: CORBA-based EJB Servers and Proprietry EJB Servers. Both support the RMI-IIOP API but how that API is implemented is a different story. (NB: By API we mean the interface provided to the client by the stub or proxy). A CORBA-based EJB Server actually implements its EJB Objects as CORBA Objects (it therefore encorporates an ORB and this means that EJB’s can be contacted by CORBA clients (as well as RMI-IIOP clients) A proprietry EJB still implements the RMI-IIOP API (in the client’s stub) but the underlying protocol can be anything. Therefore your EJBs CANNOT be contacted by CORBA clients. The difference is that in both cases, your clients see the same API (hence, your client portability) BUT how the stubs communicate with the server is different.

The EJB specification says that we cannot use Bean Managed Transaction in Entity Beans. Why?

The short, practical answer is because it makes your entity beans useless as a reusable component. Also, transaction management is best left to the application server – tha is s what they are there for. It’s all about atomic operations on your data. If an operation updates more than one entity then you want the whole thing to succeed or the whole thing to fail, nothing in between. If you put commits in the entity beans then it’s very difficult to rollback if an error occurs at some point late in the operation.

Can I invoke Runtime.gc() in an EJB?

You shouldn’t. What will happen depends on the implementation, but the call will most likely be ignored. You should leave
system level management like garbage collection for the container to deal with. After all, that’s part of the benefit of using EJBs, you don’t have to manage resources yourself.

What is clustering? What are the different algorithms used for clustering?

Clustering is grouping machines together to transparantly provide enterprise services.The client does not now the difference between approaching one server or approaching a cluster of servers.Clusters provide two benefits: scalability and high availability.

What is the advantage of using Entity bean for database operations, over directly using JDBC API to do database operations? When would I use one over the other?

Entity Beans actually represents the data in a database. It is not that Entity Beans replaces JDBC API. There are two types of Entity Beans Container Managed and Bean Managed. In Container Managed Entity Bean – Whenever the instance of the bean is created the container automatically retrieves the data from the DB/Persistence storage and assigns to the object variables in bean for user to manipulate or use them. For this the developer needs to map the fields in the database to the variables in deployment descriptor files (which varies for each vendor). In the Bean Managed Entity Bean – The developer has to specifically make connection, retrieve values, assign them to the objects in the ejbLoad() which will be called by the container when it instatiates a bean object. Similarly in the ejbStore() the container saves the object values back the the persistence storage. ejbLoad and ejbStore are callback methods and can be only invoked by the container. Apart from this, when you use Entity beans you don’t need to worry about database transaction handling, database connection pooling etc. which are taken care by the EJB container. But in case of JDBC you have to explicitly do the above features. Of course, this comes under the database transactions, but i want to add this. the great thing about the entity beans of container managed, whenever the connection is failed during the transaction processing, the database consistency is maintained automatically. the container writes the data stored at persistent storage of the entity beans to the database again to provide the database consistency. where as in JDBC API, we, developers has to do manually.

What is the role of serialization in EJB?

A big part of EJB is that it is a framework for underlying RMI: remote method invocation. You are invoking methods
remotely from JVM space
a)on objects which are in JVM space
b)possibly running on another machine on the network. To make this happen, all arguments of each method call must have their current state plucked out of JVM memory, flattened into a byte stream which can be sent over a TCP/IP network connection, and
then deserialized for reincarnation on the other end in JVM where the actual method call takes place. If the method has a return value, it is serialized up for streaming back to JVM . Thus the requirement that all EJB methods arguments and return values must be serializable. The easiest way to do this is to make sure all your classes implement java.io.Serializable.

What is EJB QL?

EJB QL is a Query Language provided for navigation across a network of enterprise beans and dependent objects defined by means of container managed persistence. EJB QL is introduced in the EJB 2.0 specification. The EJB QL query language defines finder methods for entity beans with container managed persistence and is portable across containers and persistence managers. EJB QL is used for queries of two types of finder methods: Finder methods that are defined in the home interface of an entity bean and which return entity objects. Select methods, which are not exposed to the client, but which are used by the Bean Provider to select persistent values that are maintained by the Persistence Manager or to select entity objects that are related to the entity bean on which the query is defined.