|
SCBCD Mock Questions - 7 - Answers
1)2
Required means that if the caller does not have a transactional context the container will provide the EJB with one.
Mandatory requires that the caller must be involved in a transaction before it is called. If the caller is not involved in a transaction the container will throw an exception. This exhibits the required behaviour.
Never means that the EJB will never be involved within a transaction, if there is a transactional context the container will throw an exception.
TransNewError is made up.
RequiresNew forces the container to provide the ejb with a new transactional context whenever it is called.
2)2
The method-permission element is used by the Application Assembler to specify the methods of the home and component interfaces that each security role is allowed to invoke.
ejb-transaction is not an element that exists within the deployment descriptor.
The container-transaction element is used to define the transaction attributes by the application assembler. This can be used to specify transaction attributes for the methods of Session and Entity bean home and component interfaces and for the onMessage methods of message-driven beans. Each container-transaction element has a list of one trans-attribute element and one or more method elements. The container-transaction element specifies that all the listed methods are assigned the specified transaction attribute value. All methods specified in a single container-transaction element belong to the same enterprise bean.
The cmp-field element describes a container-managed field and is used within container-managed persistence not container-managed transactions.
container-managed is not a valid element for the deployment descriptor.
3)2,4
A Session Bean or a Message-driven Bean can be designed with bean-managed transaction demarcation or with container-managed transaction demarcation (but it cannot be both at the same time).
An Entity Bean must always be designed with container-managed transaction demarcation.
The beans that a Session bean communicates with will not affect the types of transaction they can use in their individual methods.
4)2
A message-driven bean instance must commit a transaction before the onMessage method returns. The reason for this is that a message-driven bean responds to a JMS message and is not coupled with any other calls (from clients or other EJBs). This means that if a transaction were not closed before the return of the onMessage method the transaction handle would not be available to anyone and the transaction would not be able to be committed (this would eventually timeout).
5)2,3
Answer 1 is incorrect if an application exception is thrown by an enterprise bean instance the client transaction will not automatically rollback. The client will be given a chance to recover a transaction from an application exception.
Answer 2 and 3 are correct, you can force a container managed transaction rollback by using the setRollbackOnly method or if an EJBException is thrown. If an EJBException is thrown (signaling that a non application error has occurred) the container will rollback any container managed transactions.
Answer 4 is not correct, you cannot use the UserTransaction interface if you are using Container managed transactions. Only bean managed transactions can use the UserTransaction interface. If an instance of an enterprise bean with container-managed transaction demarcation attempts to invoke the getUserTransaction() method of the EJBContext interface, the Container will throw java.lang.IllegalStateException.
6)1,4
The Enterprise JavaBeans architecture supports flat transactions. A flat transaction cannot have any child (nested) transactions. As stated in the EJB specification the decision not to support nested transactions allows vendors of existing transaction processing and database management systems to incorporate support for Enterprise Java-Beans. If these vendors provide support for nested transactions in the future, Enterprise Java-Beans may be enhanced to take advantage of nested transactions.
7)3
The getRollbackOnly and setRollbackOnly methods of the MessageDriven-Context interface should be used only in the message-driven bean methods that execute in the context of a transaction. The Container must throw the java.lang.IllegalState- Exception if the methods are invoked while the instance is not associated with a transaction. (See EJB specification).
8)1
Used to notify Session Beans of events of the transaction context they are participating in. If a Session Bean class implements the javax.ejb.SessionSynchronization interface, the Container must invoke the afterBegin(), beforeCompletion(), and afterCompletion(...) callbacks on the instance as part of the transaction commit protocol.
9)2,4
An application assembler cannot affect transactional behaviour for enterprise beans that use bean-managed transaction demarcation. The application assembler can only affect transactional behaviour of beans that use container-managed transaction demarcation.
The application assembler does not necessarily have to provide the transaction attributes for an enterprise bean the Application Assembler can specify a value of none. If the transaction attributes are not specified for the methods of an enterprise bean, the responsibility rests with the Deployer who will have to specify them.
10)1
An enterprise bean with bean-managed transaction demarcation must not use the getRollbackOnly() and setRollbackOnly() methods of the EJBContext interface as these are only available for container managed transactions.
An enterprise bean that uses bean managed transactions should use the interfaces available on the UserTransaction interface i.e. UserTransaction.rollback() to rollback the transaction and UserTransaction.getStatus() to see the status of a Bean Managed Transaction.
The statement "A bean using Bean Managed Transactions is not responsible for it's own persistence", is incorrect as a bean that uses bean managed transactions will be responsible for it's own persistence. An entity bean cannot use bean managed transactions.
|