Paul Anil wrote:Congratulations!!!
Glad to know Enthuware tool helped!!!
Mikalai Zaikin wrote:
Bob Wheeler wrote:Hi,
I can proudly announce that I successfully passed the SCBCD 5 certification exam with 83%.
Hey, well done !
Congratulations !!!
amit punekar wrote:
The transaction and Persistence Context are different from each other.
amit punekar wrote:Hi,
AFAIK this condition would happen if the bean uses bean managed transactions. In this a method would start a transaction but leave it open to be committed by another method. Due to this the container will not passivate the SFSB instance as it would still be servicing the client.
amit punekar wrote:
As per the core Ejb specs a client to such bean should take care not to call remove method.
See 4.4.4 ejb core specs.
If a session bean instance is participating in a transaction, it is an error for a client to invoke the
remove method on the session object’s home or component interface object. The container
must detect such an attempt and throw the javax.ejb.RemoveException to the client.
The container should not mark the client’s transaction for rollback, thus allowing the client to
recover.
"A stateful session bean cannot be passivated if it is in a transaction."
Maciek Mike wrote:Hi,
D: If the second <auth-constraint> tag is removed, the constrained resource can be accessed by both roles.
Is wrong and answer F: