In Ejb 2.0 spec, page 460. setting transsaction attribute is listed as application assembler's job. Determmining what tx attribute a method need is very probably based on the implmentation of the method, so bean provider is the person who should set that value. I don't understand how a assembler will know what tx attribute to be assigned. Does he/she suppose to know all these ejb methods?
The bean developer does not necessarily know anything about any other beans or clients besides the ones that he wrote. So, he can't say if his methods should be run in a transaction for all clients because he does not know the details of any clients. The only thing the developer knows is whether or not his bean methods rely on CMT or BMT. The application assembler is responsible for understanding how all the beans work together. Hence, he is responsible for setting the transaction values. He knows that clientA has an existing transaction when it calls a method on beanA but that clientB does not have an existing transaction when it calls a method on beanA. The bean developer is unaware of both clientA and B and so he does not know how to set his transaction requirements. If, for example, he set his method attributes to Mandatory, it would limit his bean's reusability. For instance, clientB could not call his bean's methods.
Thanks, but I am not fully convinced. So an app assembler must have a very comprehensive knowlege of all the methods which is not easy to achieve. suppose I have a bean with a bisiness method say transfer(int amount, Account A, Account B); and I want this method to be invoked run only inside a transaction. As the implemnter of this method, I want container to throw exception when this method is invoked without a transaction context. So I will require that Mandatory to be the tx attribute. Yes I am purposely restrict the use of this method. Now how an application assmbler know excactly this trasfer method has to have a Mandatory attribute. He has to read some documentation? What if he put a Spported as the tx attribute and a future client invoke this method without a transaction context. At least, bean provider should give some clue to assembler. For me this is a bit like to the situation that some one else has to decide my method should be proteced or public. But in pracice, most of the time the bean provider also act as a assembler. I still think is a gray area. I think bean provider should be able to set the tx attribut and put in the descriptions about the reason and possible other choices. Then when application assembler try to change it, he has to think twice.
A bean developer writes components. Components are used by businesses in accordance with their business rules. The bean developer does not know the business rules. He may not even work for the business that is using his bean. You can't tell a client what his business is. A client may use your beans methods for something other than you originally thought of. If you want to provide some advice to the application assembler, there's nothing stopping you from using xml style comments in the DD.