These are all things you might be tested on. But remember, you won’t be asked a simple true or false question, like, “The getRollbackOnly() method can be called from a method with a transaction attribute of NotSupported.” (In which case the answer would be false, of course). No, you’re likely to see something much more clever, like bean code plus the bean’s deployment descriptor, and you have to decide if it all works together.
getRollbackOnly() MUST be called from a bean in a transaction!
You already know that getRollbackOnly() can be called only by CMT beans, and that the method exists only in EJBContext and NOT in UserTransaction. (Remember? BMT beans can call getStatus() on UserTransaction, but they can’t call getRollbackOnly().)
But for getRollbackOnly() to work, the method must be in a transaction, which means you MUST use only:
Message-driven beans can use only TWO attributes: Requires and NotSupported.
Think about it. A message-driven bean doesn’t have a calling client! The container calls the onMessage() method, so it doesn’t make any sense to use the other ones. RequiresNew? That’s useless because there will never be a pre-existing transaction. Mandatory? That would blow up every time (by “blow up” we mean throw an exception) because Mandatory means “Requires Pre-Existing”. Never? Well, that is always the case anyway, and Supports is silly too. You can say only two things for onMessage():
YES, I want to start a transaction ...