Thanks to Kathy and Bert for Head-First EJB ( excellent book...) also thankful to ejbcertificate.com and jdiscuss.com for the mock exams... doing the mock exams helped me a lot...
option d should also be correct, if doesn't throw the exception then how will it know about the rollback!, when the transaction is rolledback , should throw the exception , to inform that the transaction has been rolledback! when one say's the code throws exception at runtime, it's logical to assume that the container throws the exception to code and code throws the same!
can get to local reference to entity bean b in the entity bean a and set it still container figures it out and makes the reference for other to null [ August 18, 2005: Message edited by: Praveen Kumar Mathaley ]
KQ8: Which two are true about bean-managed transaction demarcation? A) A transaction used by a BMT bean MUST have been started by the bean. B) The caller's transaction will be propagated into a BMT bean. C) Transactions in a BMT bean do not propagate when the BMT bean calls a method on another bean. D) A bean cannot use both CMT and BMT together. E) BMT beans must not specify transaction attributes. the answer is D E why A,C is incorrect,
Regarding answer A, I think the wording may not be correct A BMT bean transaction should be started by same bean itself Yes C Is incorrect as Transaction from BMT Bean can be propagated to CMT Bean.
if the business method has no transaction context then simply the sessionsynchronization interface methods are not called... so,for the interface methods to be invoked, the business methods should have transaction...
a primary key can be simple string, which may be same for two different beans, but it doesn't mean that the two entity beans are same, it's just an possibility...
propagation of transaction from remote client to the bean depends on the client,if your client implements JTS ( or your client runs in a container which take cares of the transaction i.e does the work of JTS for you...) then the transaction is propagated. Note: The client and container should support distributed transactions... All the application server's don't support distributed transactions...
please refer the url [ UD: removed link to copyrighted material ]
Hi Paul, ejb is not allowed to get reference to default/current class loader? why is it so? my idea is to define helper classes for Stateful/Stateless Session Bean and load and call the method dynamically... i am confused about this limitation! also what does it mean when ejb is not allowed to define new class??
Hi paul, Stateful session bean is allowed to implement SessionSynchronization method but Stateless Session bean is not allowed! why? Stateless session bean can also be a part of transaction , i.e a transaction started by stateful session is propagated to stateless session when a method is called in a transaction or else we can specify to start new transaction everytime a method is called...
that's why it's unclear to me as of why the stateless session bean is not allowed to implement the session synchronization...
thank you in advance... Praveen [ July 26, 2005: Message edited by: Praveen Kumar Mathaley ]
addHeader - simply adds the header to the response( doesn't overwrite the existing ones..) setHeader - clears all the existing ones( i.e with same header name) and adds the header to the response...
I have more experience in servlets & jsp techs..( nearly 5 years...) and have been preparing for last 3 months( although not continuosly , but whenever got time...).. anyhow experience is nothing to do with exam, it's enough if one goes through what i have mentioned in the post...
Ranch Hand Scavenger Hunt
Number Posts (45/100)
First Post