Doubts in Enthuware mock Questions

[krishna bulusu]

Hi,

Following are the question from Enthuware.


1:Which of the following is correct regarding the SessionBeans?
1)All session beans can access javax.transaction.UserTransaction
2)All session beans can call sessionContext.setRollBackOnly()
3)All session beans may implement SessionSynchronization interface
4)All session beans can retrieve resource managers references in the ejbCreate() method.
5)None of these.
Correct Ans Acc to Enthuware: 5
but My answere:1&2.
Here we are talking about SessionBeans only not BMT session beans or CMT session beans.
Look at the option 3. it is invalid because only stateful sessionbeans could implement this interface.

2:The remove(entityObject) method on EntityManager has been called. Which of the following are correct?
1)If entityObject is new, IllegalStateException will be thrown.
2)If entityObject is already removed, IllegalStateException will be thrown.
3)It will never throw IllegalStateException.
4)None of these.
Enthu Ans: 4
My Answere:3
Remove throws IllegalArgumentException not IllegalStateException if the entity is already removed.

3:You are developing a stateless session bean OrderBean. It should have a method named checkOut() that takes list of Products. This method is supposed to be executed in the transaction started by the client. If the method finds an invalid product in the list of Products, it should allow the client to fix the problem and retry.

How would you implement this requirement?
1)Upon encountering an invalid product, the method should call EJBContext.setRollbackOnly(true) and return.
2)Upon encountering an invalid product, the method should call EJBContext.setRollbackOnly(true) and throw EJBException.
3)Upon encountering an invalid product, the method should throw an application exception named InvalidProductException with rollback attribute set to false.
4)Upon encountering an invalid product, the method should throw EJBException without calling EJBContext.setRollbackOnly(true).

Enthu Answere: 3.
MY Answere: 2&3
option 2 is perfectly valid in case of CMT. But here the question didn't specify any kind of exception. Hence, it must be the crrect one. isn't it?

[Sergio Tridente]

Hi krishna,

Originally posted by krishna bulusu:
1:Which of the following is correct regarding the SessionBeans?
1)All session beans can access javax.transaction.UserTransaction
2)All session beans can call sessionContext.setRollBackOnly()
3)All session beans may implement SessionSynchronization interface
4)All session beans can retrieve resource managers references in the ejbCreate() method.
5)None of these.
Correct Ans Acc to Enthuware: 5
but My answere:1&2.
Here we are talking about SessionBeans only not BMT session beans or CMT session beans.

We are talking about all session beans, this includes BMT and CMT.
Option 1 is only valid for BMT session beans. Option 2, only for CMT.

Originally posted by krishna bulusu:
2:The remove(entityObject) method on EntityManager has been called. Which of the following are correct?
1)If entityObject is new, IllegalStateException will be thrown.
2)If entityObject is already removed, IllegalStateException will be thrown.
3)It will never throw IllegalStateException.
4)None of these.
Enthu Ans: 4
My Answere:3
Remove throws IllegalArgumentException not IllegalStateException if the entity is already removed.

That's right: if the entity is already removed, then IllegalArgumentException is thrown by the EntityManager.remove() method (this makes enthuware's explanation invalid). However, an IllegalStateException is thrown if the EntityManager has already been closed when you call the remove() method, which can happen with application managed persistence contexts.
So, the answer given by enthuware is right but for a different reason.

Originally posted by krishna bulusu:
3:You are developing a stateless session bean OrderBean. It should have a method named checkOut() that takes list of Products. This method is supposed to be executed in the transaction started by the client. If the method finds an invalid product in the list of Products, it should allow the client to fix the problem and retry.

How would you implement this requirement?
1)Upon encountering an invalid product, the method should call EJBContext.setRollbackOnly(true) and return.
2)Upon encountering an invalid product, the method should call EJBContext.setRollbackOnly(true) and throw EJBException.
3)Upon encountering an invalid product, the method should throw an application exception named InvalidProductException with rollback attribute set to false.
4)Upon encountering an invalid product, the method should throw EJBException without calling EJBContext.setRollbackOnly(true).

Enthu Answere: 3.
MY Answere: 2&3
option 2 is perfectly valid in case of CMT. But here the question didn't specify any kind of exception. Hence, it must be the crrect one. isn't it?

Option 2 is not correct because it has been defined that "it should allow the client to fix the problem and retry", which means that you should not rollback the transaction in order to give the client the opportunity to correct the problem and retry (in the context of the same transaction).
[ September 04, 2008: Message edited by: Sergio Tridente ]

[krishna bulusu]

Hi Sergio Tridente,

Thank you very much for your Reply.

[Paul Anilprem]

Originally posted by Sergio Tridente:
That's right: if the entity is already removed, then IllegalArgumentException is thrown by the EntityManager.remove() method (this makes enthuware's explanation invalid). However, an IllegalStateException is thrown if the EntityManager has already been closed when you call the remove() method, which can happen with application managed persistence contexts.
So, the answer given by enthuware is right but for a different reason.

The answer provided is correct. There is a difference between a "removed" entity and a "detached" entity. If you try to remove an entity that is already removed, the call is ignored. But it you try to remove an entity that is detached, IllegalArgumentException is thrown.

3.2.2 Removal
A managed entity instance becomes removed by invoking the remove method on it or by cascading the
remove operation.
The semantics of the remove operation, applied to an entity X are as follows:
� If X is a new entity, it is ignored by the remove operation. However, the remove operation is
cascaded to entities referenced by X, if the relationship from X to these other entities is annotated
with the cascade=REMOVE or cascade=ALL annotation element value.
� If X is a managed entity, the remove operation causes it to become removed. The remove operation
is cascaded to entities referenced by X, if the relationships from X to these other entities
is annotated with the cascade=REMOVE or cascade=ALL annotation element value.
� If X is a detached entity, an IllegalArgumentException will be thrown by the remove
operation (or the transaction commit will fail).
� If X is a removed entity, it is ignored by the remove operation.
� A removed entity X will be removed from the database at or before transaction commit or as a
result of the flush operation.
After an entity has been removed, its state (except for generated state) will be that of the entity at the
point at which the remove operation was called.

[Sudarshan Sreenivasan]

rollback attribute set to false.

What does the above imply.
How can i achieve this ?

[Sudarshan Sreenivasan]

Hi,

I somehow realize how stupid my earlier post was !!
Anyways for the benefit of the few ranchers who are as stupid as me and have the same dout
Please refer to the below link
application Exception

[Sudarshan Sreenivasan]

All session beans can retrieve resource managers references in the ejbCreate() method.

Why is this not true ?

Spec says the below operations can be done by PostConstruct

SessionContext methods: getBusinessObject,
getEJBHome, getEJBLocal-
Home, getCallerPrincipal,
isCallerInRole, getEJBObject, getEJBLocalObject,
lookup
JNDI access to java:comp/env
Resource manager access
Enterprise bean access
EntityManagerFactory access
EntityManager access

[Ralph Jaus]

Spec says the below operations can be done by PostConstruct

Your list only holds for stateful session beans. For stateless session beans see core spec 4.5.2, table 2.

[Sudarshan Sreenivasan]

Yes i get it now ... i think i also pasted the wrong section of the spec here.