Java开发网 - SCBCD study notes (1)

Topic: SCBCD study notes (1)

1.SCBCD study notes (1)

Posted by: jamesfeng2
Posted on: 2004-06-17 18:05

Which of the following statements regarding the session bean interface are correct? [Check all correct answers]
1. All session beans must implement the SessionBean interface.
2. The container calls unsetSessionContext() to unset the associated session context.
3. The container notifies a stateless session bean by calling ejbPassivate() on the bean instance entering the "passive" state.
4. The container invokes ejbRemove() on a stateless bean instance when it no longer needs the instance and wishes to reduce the number of bean instances in the method-ready pool.
5. The ejbActivate method is a suitable place to open a database cursor that was previously closed in the ejbPassivate method of a stateful session bean.
Answers 1, 4 and 5 are correct. Answer 1 is correct because all session beans must implement the SessionBean interface. Answer 4 is correct. There is no relationship between a client's invocation of a remove operation with the container calling ejbRemove(). The container invokes ejbRemove() when it no longer needs the instances and wishes to reduce the number of instances in the method-ready pool. Answer 5 is correct the container cannot retain open resources when a bean instance is passivated. The bean provider must therefore ensure that any open resources are closed in the ejbPassivate method and reopened in the ejbActivate method.

Answer 2 is incorrect. Unlike the EntityBean interface which has unsetEntityContext() to correspond with setEntityContext(), there is no unsetSesssionContext method defined by the SessionBean interface. If the developer provides an unsetSessionContext method in a session component interface, the container will never call it.

Answer 3 is incorrect because the container never passivates stateless session beans since they do not maintain conversational state.

Which of the following responsibilities relating to a stateful session bean's ejbPassivate method belong to the container? [Check all correct answers]
1. Providing notification that a bean instance is about to be passivated.
2. Ensuring that the bean's instance fields meet the requirements for passivation.
3. Closing any open socket connections.
4. Saving a SessionContext interface object reference that is stored in the bean instance's state.
5. Saving an UserTransaction interface object reference that is stored in the bean instance's state
Answers 1, 4, and 5 are correct. The purpose of the ejbPassivate method in a stateful session bean is to allow the container to notify the bean provider of its intent to passivate the bean instance. If references to an javax.ejb.SessionContext interface or javax.transaction.UserTransaction interface are stored in the instance's state it is the container's responsibility to save and restore the objects references after invoking ejbPassivate(). The container can replace the original object with a different but functionally equivalent objective during activation.

Answers 2 and 3 are incorrect because they are the responsibility of the bean provider.

Which one of the following methods provides notification that the current transaction has completed?
1. javax.ejb.SessionBean.ejbPassivate()
2. javax.ejb.SessionBean.ejbRemove()
3. javax.ejb.SessionSynchronization.afterCompletion(boolean)
4. javax.ejb.SessionSynchronization.beforeCompletion(boolean)
5. javax.ejb.SessionSynchronization.transactionCompleted(boolean)
Answer 3 is correct. javax.ejb.SessionSynchronization.afterCompletion(boolean) informs a stateful session bean that implements the SessionSychronization interface when the current transaction has completed. A completion status is passed to the method; true for a committed transaction and false if a rollback has occurred. If a rollback has occurred, afterCompletion() is a good place to reset any cached instance variables to the values prior to beginning the transaction.

The container controls the lifecycle of a stateless session bean. Although a client can invoke the create and remove methods on the home interface of a stateless session bean, the container decides when to create and remove the session object.

What are the uses of the ejbPassivate method in a stateful session bean? [Check all correct answers]
1. To allow the container to persist a stateful session bean's conversational state to secondary storage.
2. To allow the container to notify the bean provider of its intent to passivate a bean instance.
3. For the bean provider to ensure that the bean's state meets the requirements to allow the container to persist the state to secondary storage.
4. For the bean provider to efficiently manage the number of session beans in the container's instance pool.
5. For the bean provider to release any open resources

Answers 2, 3 and 5 are correct. The purpose of the ejbPassivate method in a stateful session bean is to allow the container to notify the bean provider of its intent to passivate the bean instance. ejbPassivate() is invoked by the container before passivating the bean instance giving the bean provider an opportunity to ensure that the bean's state meets the requirements for passivation and to allow the bean provider to release any open resources (open resources cannot be retained across an instance's passivation).

Answer 1 is incorrect. The container does not use the ejbPassivate method to persist the session bean's conversational state. The state is persisted by the container after invoking ejbPassivate(). Answer 4 is incorrect. The bean provider does not use ejbPassivate() to efficiently manage the number of session beans in the container's instance pool. Again, this is the responsibility of the container after invoking ejbPassivate().

The conversational state of a stateful session bean may hold resources such as open socket connections and open database cursors. However, the container cannot retain the open resources when the bean instance is passivated. The bean provider must therefore ensure that the open resources are closed in the ejbPassivate method and reopened in the ejbActivate method.

A session bean's conversational state is not transactional and is not automatically reset to its initial state if a transaction is rolled back. The afterCompletion notification may be used to manually reset the bean instance's conversational state in the event of a transaction roll back

Non-transient fields of a session bean's conversational state are maintained across the instance's passivation.

Which of the following responsibilities related to session bean's belong to the EJB container provider? [Check all correct answers]
1. Affecting transaction management of a session bean with container-managed transaction demarcation.
2. Handling of a system exception thrown by a session bean's business method.
3. Defining the session bean class.
4. Deciding whether a session bean should use either container-managed or bean-managed transaction demarcation.
5. Supplying resource connections used by an enterprise bean.
Answers 1 ,2 and 5 are correct. Answers 1 and 5 are correct because the EJB container provider intercepts every client method invocation on a session bean object via the bean's home and component interface and requests for connections to resource managers to affect the enterprise bean’s transaction management. Answer 2 is correct. When a system exception is thrown by a session bean's business method and a transaction context exists, the container logs the exception, marks or rolls back the transaction, discards the bean instance and then throws an exception to the client.

Answers 3 and 4 are incorrect as they are the responsibilities of the bean provider.

Which one of the following responsibilities related to session beans belong to the bean provider?
1. Ensuring that only one thread can execute a bean instance at anyone time.
2. Managing the session bean instances at runtime.
3. Supplying resource connections used by an enterprise bean.
4. Deciding whether a session bean should use either container-managed or bean-managed transaction demarcation.
5. Handling of a system exception thrown by a session bean's business method.
Answer 4 is correct. When designing an enterprise bean, the bean provider must decide, based on the transaction attributes in the deployment descriptor, whether a session bean uses container-managed or bean-managed transaction demarcation.

Answers 1, 2, 3, and 5 are incorrect as they are the responsibilities of the EJB container provider.

Which of the following statements only apply to stateful session beans? [Select all correct answers]
1. Maintained by the container in a pool of available instances.
2. Ability to receive notification by the container of transaction boundaries.
3. Maintains conversational state across several business method calls.
4. A transaction started in a business method must be committed before the method completes.
5. Receives notification from the container when the bean instance is activated.
Answers 2, 3, and 5 are correct. Answer 2 is correct because only stateful session beans can implement the SessionSynchronization interface. A session bean that implements the SessionSynchronization interface is provided with transaction synchronization notifications from the container. Answer 3 is correct because only stateful session beans maintain conversational state, whereas stateless session bean don't. Answer 5 is correct. Only stateful session beans are passivated and activated by the container because they have conversational state that require preservation when the container decides to conserve resources.

Answers 1 and 4 are incorrect because they only apply to stateless session beans.

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

An enterprise bean with container-managed transaction demarcation can use the setRollbackOnly method to mark the current transaction for rollback. setRollbackOnly() can only be used in an enterprise bean instance method if the bean is associated with a transactional context. The afterBegin and beforeCompletion methods will always have the same transaction context as the business methods executed between them.

setSessionContext(), ejbRemove(), and afterCompletion() have an unspecified transaction context. Calling setRollbackOnly() in any of these methods results in java.lang.IllegalStateException been thrown.

Which of the given scenarios results in a stateless session bean instance being removed by the container without calling ejbRemove() on the bean instance? [Check all correct answers]
1. The bean instance throws javax.ejb.EJBException to the container.
2. The bean instance throws an application exception to the container.
3. The bean instance has timed out whilst in the passivated state.
4. setRollbackOnly on the session context is called.
5. The container crashes.
Answers 1 and 5 are correct. The container is not guaranteed to invoke the ejbRemove method on a session bean instance if a system exception is thrown. javax.ejb.EJBException is usually thrown by a bean provider to wrap any system exceptions that are checked exceptions; for example, java.sql.SQLException and javax.naming.NamingException. Answer 5 is correct because if the container crashes, ejbRemove() is not guaranteed to be invoked on the session bean.

Answers 2 and 4 are incorrect because they do not cause the container to remove the session bean. Answer 3 is incorrect because stateless session beans are never passivated since they have no state to save.

Which of the following statements regarding the lifecycle of a session bean are correct? [Check 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.
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.

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?
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.
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 Envelope

;
}
...
}
public void ejbRemove() {
try {
con.close();
} catch (SQLException se) {
throw new EJBException Envelope

;
}
}
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.

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!

Which of the following SessionContext methods are accessible in the setSessionContext method of a session bean class? [Check all correct answers]
1. getEJBHome()
2. getEJBLocalHome()
3. getEJBObject()
4. getEJBLocalObject()
5. getCallerPrinciple()
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

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().
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. After 4 is incorrect because the container only calls beforeCompletion on the bean instance if a transaction commit has been requested.

--------------------
SCJP,SCWCD,SCBCD