Someone might want to back me up on this, but according to the Headfirst book, I believe, Supports makes the bean difficult to code: As the bean provider, you're going to want to know if your methods are or aren't being run in a meaningful transaction context, but you can't know that with Supports. For example, given a CMT entity bean with Supports, what's going to happen if your business method calls getRollbackOnly() on the bean's context? Well, if there happens to be a transaction, fine, but if there's no transaction, then you're going to get an IllegalStateException...
Supports, Never and NotSupported transaction attribute for CMT allow the Container to execute the methods under an "unspecified transaction context", which could simply mean anything: 1. With a transaction 2. Without a transaction 3 With multiple transactions etc. The EJB Spec gives the EJBContainer/Vendor much flexibilty in implementing these transaction attributes. Normally the vendors implement Never and NotSupported correctly to some extent, but they take a lot of liberty when it comes to "Supports" attribute. It is not just YES or NO, but needs to support a client transaction if one exists and should not support a client transaction, if it doesn't exist. So due to this "dual-semantics", transaction attribute "supports" is to be used with caution. I cannot remember, where I have read this that it is optional for the EJB Vendors to implement supports, NotSupported and Never transaction attribute. So I wouldn't surprised if these transaction attributes are not supported at all, by an application server.
Why fit in when you were born to stand out? - Seuss. Tiny ad:
Devious Experiments for a Truly Passive Greenhouse!