SCBCD Mock Questions - 14 - 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.