EJB Interview Questions

51. 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.

However, the J2EE spec is explicit:

• 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)

52. How to implement an entity bean which the PrimaryKey is an auto numeric field?

The EJB 2 Spec (10.8.3 – Special case: Unknown primary key class) says that in cases where the Primary Keys are generated automatically by the underlying database, the bean provider must declare the findByPrimaryKey method to return java.lang.Object and specify the Primary Key Class as java.lang.Object in the Deployment Descriptor.

53. When defining the Primary Key for the Enterprise Bean, the Deployer using the Container Provider’s tools will typically add additional container-managed fields to the concrete subclass of the entity bean class.

In this case, the Container must generate the Primary Key value when the entity bean instance is created (and before ejbPostCreate is invoked on the instance.)

54. What is clustering?

Clustering is grouping machines together to transparently provide enterprise services. Clustering is an essential piece to solving the needs for today’s large websites.

The client does not know the difference between approaching one server and approaching a cluster of servers.

55. Is it possible to share an HttpSession between a JSP and EJB?

What happens when I change a value in the HttpSession from inside an EJB? You can pass the HttpSession as parameter to an EJB method, only if all objects in session are serializable.This. This has to be consider as “passed-by-value”, that means that it’s read-only in the EJB. If anything is altered from inside the EJB, it won’t be reflected back to the HttpSession of the Servlet Container.

56. If my session bean with single method insert record into 2 entity beans, how can know that the process is done in same transaction (the attributes for these beans are Required)?

If your session bean is using bean-managed transactions, you can ensure that the calls are handled in the same transaction by :

 javax.transaction.UserTransaction tran= null; try{ tran=ctx.getUserTransaction(); tran.begin(); myBeanHome1.create(....); myBeanHome2.create(...); tran.commit(); }catch(...){} 

You may want to check if you’re already running in a transaction by calling tran.getStatus().

57. When should I adopt BMP and when I should use CMP?

You can use CMP and BMP beans in the same application… obviously, a bean can be BMP or CMP, not both at the same time (they are mutually exclusive).

There is a common approach that is normally used and considered a good one. You should start developing CMP beans, unless you require some kind of special bean, like multi-tables, that cannot be completely realized with a single bean. Then, when you realize that you need something more or that you would prefer handling the persistence (performance issue are the most common reason), you can change the bean from a CMP to a BMP.

58. What’s different in Enterprise JavaBeans 1.1?

The most significant changes are listed below:

• Entity bean support, both container- and bean-managed persistence, is required.
• Java RMI-IIOP argument and reference types must be supported, but any protocol can still be used including IIOP, JRMP, HTTP, or a proprietary protocol. In other words, the client API must support the Java RMI-IIOP programming model for portability, but the underlying protocol can be anything.
• The javax.ejb.depoyment package has been dropped in favor of a XML based deployment descriptor
• Declarative security authorization (access control) has changed to be more role driven. Also the runAs declarations have been eliminated.
• Declarative isolation levels are no longer available. Isolation levels are now managed explicitly through JDBC (BMP), the database or other vendor specific mechanisms.
• The bean-container contract as been enhanced to include a default JNDI context for accessing properties, resources, (JDBC, JMS, etc), and other beans.
• The basic EJB roles have been expanded and redefined to better separate responsibilities involved in the development, deployment, and hosting of enterprise beans.

59. What is Enterprise JavaBeans?

Enterprise JavaBeans (EJB) is Sun Microsystems’ specification for a distributed object system similar to CORBA and Microsoft Transaction Server, but based on the Java platform. EJB specifies how developers should build components that can be accessed remotely and how EJB vendors should support those components. EJB components, called enterprise beans, automatically handle transactions, persistence, and authorization security, so that the developer can focus on the business logic.

60. What is an enterprise bean?

An enterprise bean is a server-side component — defined in the Java technology — which adheres to the Enterprise JavaBeans server-side component model. A server-side component is business object that can be accessed remotely. Many server-side component models exist: CORBA specifies CORBA objects; Microsoft Transaction Server (MTS) defines COM/DCOM; and EJB specifies enterprise beans.

Enterprise beans can be developed to represent business concepts like Employee, Order, Travel Agent, etc. Enterprise beans can be assembled into applications that solve enterprise business problems.

EJB has two basic types of enterprise beans: Session and Entity. Depending on the type of enterprise bean used, features like persistence, transactions, security, and multiple concurrent access can be managed automatically.

61. Are Enterprise JavaBeans and JavaBeans the same thing?

Enterprise JavaBeans and JavaBeans are not the same thing; nor is one an extension of the other. They are both component models, based on Java, and created by Sun Microsystems, but their purpose and packages (base types and interfaces) are completely different.

JavaBeans

The original JavaBeans specification is based on the java.beans package which is a standard package in the JDK. Components built on the JavaBeans specification are intraprocess components that live in one address space and are typically used for Graphical User Interface (GUI) as visual widgets like buttons, tables, HTML viewers, etc.

Enterprise JavaBeans

The EJB specification is based on the javax.ejb package, which is a standard extension package. Components built on the EJB specification are intraprocess components that live in multiple address spaces as distributed object. These components are used as transactional business objects that are accessed as remote objects.

62. How does passivation work in stateful session beans?

Unlike entity beans and stateless session beans, stateful session bean are usually evicted from memory when they are passivated. This is not true of all vendors but this view serves as good model for understanding the concepts of passivation in session beans.

When a stateful bean experiences a lull in use — between client invocations and transactions — the container may choose to passivate the stateful bean instance. To conserve resources the bean instance is evicted from memory (dereferenced and garbage collected). When the EJB object receives a new client request, a new stateful instance is instantiated and associate with the EJB object to handle the request.

Stateful beans maintain a conversational state, which must be preserved before the bean instance is evicted from memory. To accomplish this, the container will write the conversational state of the bean instance to a secondary storage (usually disk). Only the non-transient serializable instance fields are preserved. When the bean is activated the new instance is populated with the preserved state. References to live resources like the EJBContext, DataSource, JNDI ENC, and other beans must also be maintained somehow — usually in memory — by the container.

The javax.ejb.SessionBean interface provides two callback methods that notify the bean instance it is about to passivated or was just activated. The ejbPassivate( ) method notifies the bean instance that it is about have its conversational state written to disk and be evicted from memory. Within this method the bean developer can perform operations just prior to passivation like closing open resources. The ejbActivate( ) method is executed just after a new bean instance has been instantiated and populated with conversational state from disk. The bean developer can use the ejbActivate( ) method to perform operations just prior to servicing client request, like opening resources.

63. How does a client application create a transaction object?

How you gain access to UserTransaction objects varies depending on the type of client. Enterprise JavaBeans provides two types of transaction management:

• Container-managed transactions. As the name implies, the EJB container makes the decisions (based on the deployment descriptor’s trans-attribute setting) regarding how to bundle operations into transactions and then works with the transaction manager, which manages the transaction processing.
• Bean-managed transactions. In this case, a session bean obtains the UserTransaction object via the EJBContext using the getUserTransaction() method.

JMS clients can bundle several messages in a transaction simply by using a transactional session–a UserTransaction object is not required. To create a transactional session, use either QueueConnection.createQueueSession() or TopicConnection.createTopicSession() with true as the first argument. (Some JMS implementations support JTA, so that it’s also possible to obtain a UserTransaction object from the JMS server.)

In other environments, for example, a web server that supports servlets and/or JavaServer Pages (JSP), a JMS server, and others, you obtain a UserTransaction object via JNDI. Of course, for a servlet to obtain a UserTransaction object, there must be a JTS-capable server to deliver the object.

Typically, the server provides the JNDI look-up name either directly or via a system or server property. For example, with the WebLogic server, you would use a code segment similar to the following:

 ... Context c = new InitialContext(); UserTransaction ut = (UserTransaction) c.lookup("javax.jts.UserTransaction"); ut.begin(); // perform multiple operations... ut.commit() ... 

With J2EE implementations, you obtain the UserTransaction object with a code segment similar to the following:

 ... Context c = new InitialContext(); UserTransaction ut = (UserTransaction) c.lookup("java:comp/UserTransaction"); ut.begin(); // perform multiple operations... ut.commit() ... 

If the environment provides the UserTransaction object via a system property, you would use a code segment similar to the following:

 ... String transName = System.getProperty("jta.UserTransaction"); Context c = new InitialContext(); UserTransaction ut = (UserTransaction) c.lookup(transName); ut.begin(); // perform multiple operations... ut.commit() ... 

JNDI remote look-up names and property names vary, of course, across servers/environment.

64. 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.

65. 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.

66. 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.)

67. 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.

68. 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.

69. 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.

70. How do you configure a session bean for bean-managed transactions?

You must set transaction-type in the deployment descriptor.

71. 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.

72. 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.

73. 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.

74. 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.

75. 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. 

Comments

comments