Originally posted by Rashmi Tambe:
EJB spec Page 314, topic 15.4 states that-
Durable topic subscriptions, as well as queues, ensure that messages are not missed even if the EJB
server is not running.
How is this possible? If the server is not running, then even the JMS message service is down. Then who will
receive the message sent by the message producer/publisher? In HFE, page 450, says that-
Topic subscriber can request a durable subscription if he wants to make sure that he sees all messages
including the one that accumulated while he was offline
I think this meaning of durable subscription makes sense than in EJB spec. Can some body clarify this?
Originally posted by Rajnish Bhasin:
I guess there can be BMT Entity beans(What if u use Bean Managed Persistence and want to manage yr Transactions), just that the exam is not supposed to cover such a thing.
Originally posted by si yi:
First client can invoke create() and remove() on stateless session bean
when client invoke create() on it just create EJBObject
when client invoke remove() on it just kill EJBObject.
above is my understanding, is right?
The reasons for disallowing the operations in Table 2 follow:
� Invoking the getRollbackOnly and setRollbackOnly methods is disallowed in the
session bean methods for which the Container does not have a meaningful transaction context,
and to all session beans with bean-managed transaction demarcation.
� Accessing resource managers and enterprise beans is disallowed in the session bean methods for which the Container does not have a meaningful transaction context or client security context.
Originally posted by Viktor Sadovnikov:
"All possible bean things" are allowed in BMT stateful session beans only. But when you use BMT, you are not allowed to use get/setRollbackOnly(). Instead you can call commit() or rollback()
Originally posted by sonali rao:
Mock exam question: which of the follow methods must the bean provider implement in an entity bean class? 1.ejbFind 2.ejbSelect 3.unsetEntityContext 4.ejbLoad 5.setRollbackOnly