SCBCD Mock Questions - Session Bean Lifecycle

1)Which of the following SessionContext methods is a disallowed operation for a session bean with container-managed transaction demaraction?

1)getEJBHome()
2)getCallerPrinciple()
3)getEJBObject()
4)getUserTransaction()
5)isCallerInRole()

2)Which of the following statements regarding the lifecycle of a session bean are correct?

1)java.lang.IllegalStateException is thrown if SessionContext.getEJBObject() is invoked when a stateful session bean instance is passivated.
2)SessionContext.getRollbackOnly() does not throw an exception when a session bean with bean-managed transaction demarcation is activated.
3)An exception is not thrown when SessionContext.getUserTransaction() is called in the afterBegin method of a bean with container-managed transactions.
4)JNDI access to java:comp/env is permitted in all the SessionSynchronization methods of a stateful session bean with container-managed transaction demarcation.
5)Accessing resource managers in the SessionSynchronization.afterBegin method of a stateful session bean with bean-managed transaction does not throw an exception.

3)Which of the following statements regarding the lifecycle of a session bean are correct? [Select all correct answers]

1)java.lang.IllegalStateException is thrown if setRollbackOnly() is called in a container-managed session bean's business method that has been declared with the Required transaction attribute.
2)Calling getCallerPrincipal() is disallowed in the session bean methods for which the container does not have a meaningful transaction context.
3)The UserTransaction interface is available to enterprise beans with bean-managed transaction demarcation.
4)Calling getEJBObject() in a session bean instance method is disallowed if the session bean does not define a remote client view.
5)All container providers must support the SessionSynchronization interface.

4)Given the following fragment of code of a stateful session bean, which of the following scenarios result in the session bean being removed by the container without closing the database connection?

Assume that all reference variables have been declared 
properly and the code has been compiled successfully.
InvalidExamException is a subclass of java.lang.Exception. 
  
public void ejbCreate() throws CreateException {
   // obtain database connection
}
public void completeExam() throws InvalidExamException {
   ... 
   try {
      PreparedStatement stmt = con.prepareStatement(
          "update exam set status='complete'");
      stmt.execute();
   } catch (SQLException e) {
      throw new EJBException(e);
   }
   ...     
}
public void ejbRemove() {
   try {
      con.close();
   } catch (SQLException se) {
      throw new EJBException(e);
   }	
}

1)completeExam() throws InvalidExamException.
2)The SQL statement fails to update the exam table in the completeExam() method.
3)The bean instance have been activated at least one.
4)The bean instance is passivated.
5)The client calls remove() on the corresponding session object.

5)What is the correct sequence order of method calls made by the container in order to place a stateful session bean in the method ready state?

1)create, constructor, setSessionContext, ejbCreate
2)constructor, ejbCreate, setSessionContext, ejbActive
3)constructor, setSessionContext, ejbCreate
4)setSessionContext, ejbActivate, ejbCreate
5)ejbCreate, ejbActivate, setSessionContext

6)Which of the following statements regarding the lifecycle of a stateless session bean are correct? [Select all correct answers]

1)Stateless session beans are never passivated; the ejbActivate and ejbPassivate methods are never called.
2)afterBegin, beforeCompletion and aftercompletion are callbacks methods made by the container if a container-managed stateless session bean implements the SessionSychronization interface.
3)Stateless session beans are not associated with a particular client. The container simply delegates to any free bean instance in the pool.
4)When a client invokes the create method on a stateless session bean's home interface, the container always invokes newInstance on the session bean class to create a stateless instance
5)When a client invokes the remove method on a stateless session bean's home interface, the container always removes the corresponding stateless instance from the method-ready pool

7)Given that a stateful session bean implements the SessionSychronisation interface, select the correct order in which a container calls a transactional business method that throws a system exception.

1)beforeBegin(), business method, afterCompletion().
2)beforeBegin(), business method, beforeCompletion(), afterCompletion()
3)beforeBegin(), afterBegin(), business method, afterCompletion().
4)afterBegin(), business method, beforeCompletion(), afterCompletion().
5)afterBegin(), business method, afterCompletion().

8)Which method can access an enterprise bean in a consistent manner for a container managed stateful session bean that implements the SessionSynchronization interface?

1)constructor()
2)setSessionContext()
3)ejbCreate()
4)beforeCompletion()
5)afterCompletion()

9)Which of the following SessionContext methods are accessible in the setSessionContext method of a session bean class? [Select all correct answers]

1)getEJBHome()
2)getEJBLocalHome()
3)getEJBObject()
4)getEJBLocalObject()
5)getCallerPrinciple()

10)Which of the given scenarios result in a session bean instance being removed by the container without calling ejbRemove() on the bean instance?

1)When a transaction is rolled back in a bean instance's method.
2)The bean instance is passivated.
3)The bean instance has timed out whilst in the passivated state.
4)The bean instance is removed from the method-ready pool.
5)A bean instance throws an application exception to the container

Answers:

1)4

Answer 4 is correct. The UserTransaction interface is unavailable to session beans with container-managed transaction demarcation.

Answers 1, 2, 3 & 5 are incorrect because the methods are available to session beans with container-managed transaction demarcation.

2)4

Answer 4 is correct. JNDI access to java:comp/env is permitted in a session bean's setContextMethod, ejbCreate, ejbRemove, ejbActivate, and ejbPassivate methods. For session beans that implement SessionSynchronization, all SessionSynchronization methods also have JNDI access to java:comp/env. JNDI access to java:comp/env is only disallowed in the constructor in a session bean class.

Answer 1 is incorrect. Calling getEJBObject() is only disallowed in the bean's constructor and setSessionContext method because no session object identity has been established for the instance.

Answer 2 is incorrect because SessionContext.getRollbackOnly() is not available to session beans with bean-managed transaction demarcation.

Answer 3 is incorrect. The UserTransaction interface is unavailable to session beans with container-managed transaction demarcation.

Answer 5 is incorrect because A session bean with bean-managed transaction cannot implement the SessionSynchronization interface.

3)3,4,5

Answers 3, 4 and 5 are correct. Answer 3 is correct because the UserTransaction interface is only available to enterprise beans with bean-managed transaction demarcation and unavailable to enterprise beans with container-managed transaction demarcation.

Answer 4 is correct. getEJBObject() can only be invoked in a session bean instance method if the session bean defines a remote client view.

Answer 5 is correct. All container providers must support the SessionSynchronization interface; however, implementing the interface is optional for the bean provider.

Answer 1 is incorrect. The setRollbackOnly method of the Sessioncontext interface can be called in a container-managed session bean's business method if the method is declared with a transactional attribute that creates a transactional context. Transactional attributes that cause the container to create a transactional context include Required, RequiresNew and Mandatory.

Answer 2 is incorrect. Calling getCallerPrincipal() is disallowed in session bean methods for which the container does not have a client security context.

4)2

Answer 2 is correct. A system exception thrown from a bean instance's method results in the container removing the session bean instance and not calling ebjRemove() on the instance. This results in the database connection not being closed. A system exception indicates a problem with the services that support the bean such as a SQL insert failure. In this example, since recovery from a SQLException is not always possible and is also a checked exception, javax.ejb.EJBException is thrown wrapping the original exception. When the container encounters the EJBException, the bean instance is removed without calling ejbRemove() on it.

Answer 1 is incorrect. InvalidExamException is considered as an application exception. The container simply passes the exception to the client without removing the session bean instance.

Answers 3 and 4 are incorrect. The container does not remove a bean instance when it is neither activated nor when it is passivated unless there is a period of client inactivity on the bean instance that exceeds a specified timeout period configured by the deployer. In this case, the container removes the bean instance without calling ejbRemove().

Answer 5 is incorrect because a client calling remove on the corresponding session object will cause the container to call ebjRemove() and hence close the connection.

Learn more...

Note that releasing resources only in the ejbRemove method is considered bad practice since the bean provider cannot guarantee that the container calls ejbRemove() on a session bean instance. Instances typically release the same resources in both the ejbRemove method and the ejbPassivate method. Note that releasing resources in both methods still does not cover the scenario when the EJB container crashes!

5)

Answer 3 is the correct answer. The container calls the no-arg constructor of the session bean class by invoking newInstance() on the session bean class. This creates a session bean instance. The container then calls setSessionContext() and ejbCreate<Method>(...) on the instance and returns the session object reference to the client. At this point, the session bean is in the method ready state waiting to receive a business method call from the client. This sequence of events is initiated when the client calls a create<Method>(...) method on the session bean's home interface.

Answer 1 is incorrect because the client calls the create method, and not the container. Answers 2, 4, and 5 are the wrong sequence of events.

6)1,3

Answers 1 and 3 are correct. Answer 1 is correct. Stateless session beans are never passivated since they have no state to save. The container just creates them when required and destroys them when not needed.

Answer 3 is correct. Since stateless session beans do not have conversational state, all instances of a stateless session beans are equivalent. Therefore the container can choose to delegate a client-invoked method to any available instance in a pool.

Answer 2 is incorrect because stateless session beans must not implement the SessionSynchronization interface.

Answer 4 is incorrect because the container maintains a pool of stateless instances and delegates a client request to any available instance that is in the method-ready state. A new stateless session bean instances are created when is it necessary to handle an increase in client work load.

Answer 5 is incorrect. Although a client can invoke the remove on the home interface of a stateless session bean, there are no fixed mappings between the client and the stateless instances. The container decides when to remove the session object.

7)5

Answer 5 is correct. When a transactional business method is called, the container informs the session bean instance that a new transaction has begun by calling afterBegin() on the instance. afterBegin() is called before the business method, and subsequent business methods on the instance are invoked in the context of the transaction. If a business method raises a system exception whilst in the context of transaction, afterCompletion() is called on the session bean instance with a boolean value of false to notify the instance that a rollback has occurred.

Answers 1, 2 and 3 are incorrect because the SessionSychronization interface does not define a method called beforeBegin.

Answer 4 is incorrect because the container only calls beforeCompletion on the bean instance if a transaction commit has been requested.

8)4

Answer 4 is correct. beforeCompletion() informs a session bean instance that the current transaction is about to be committed. Since the bean instance has a transactional context, the behaviour of executing beforeCompletion() is guaranteed by the container.

Answers 1, 2, 3 and 5 are incorrect. The constructor(), setSessionContext(), ejbCreate(), and afterCompletion() methods are executed with an unspecified transaction context; hence, the behaviour of executing the methods cannot be relied on.

9)1,2

Answers 1 and 2 are correct. In the lifecycle of a session bean, the container invokes setSessionContext after a session bean instance is created but before a session object identity is associated with the bean instance. Therefore, the methods (getEJBHome and getEJBLocalHome) used to obtain a session home interface can be called within the setSessionContext method.

Answers 3 and 4 are incorrect. Since an object identity has not yet been assigned by the container, the session object is inaccessible and cannot be retrieved by the getEJBObject and getEJBLocalObject methods.

Answer 5 is incorrect because getCallerPrinciple() is only accessible in session bean class methods which have a security context.

10)3

Answer 3 is correct. If a bean instance has timed out whilst in the passivated state, the container may remove the session bean. This results in the container not calling ejbRemove() on the session bean instance.

Answers 1, 2 and 5 are incorrect because they do not cause the container to remove the session bean. Answer 4 is incorrect because the contain calls ejbRemove() before removing the session bean.