Ok, think this through. The accessors and mutators of Entity beans are automatically generated by the container from abstract methods in your class -- you don't code them. Thus if you were to try to put in BMT code, where would it go? Kyle
Again, think it through. ejbLoad() and ejbStore() are called through the JTA mechanism. Where would you put the calls to JTA to make this make sense? It'd be too easy for people to try to put the JTA calls INSIDE ejbLoad() and ejbStore(), which would result in an endless loop. You could try to restrict yourself to putting them in the accessors and mutators, but then again that's a bad idea too -- miss one and you're hosed. All in all, CMT is a much better idea where Entities are concerned. Kyle
thanks. It looks like the entity beans were not designed to be used with BMT at all. One of the things that often comes to mind for developers like me is to visualize a method in the BMP entity bean containing lengthy business logic with BMT transactions used inside the method for some lines of code. I guess such code should be moved to session beans and entity beans are meant to act as pure persistence-object wrappers for the relational table(s) in the database. [ April 19, 2004: Message edited by: Vishwa Kumba ]
The answer is not very intuitive, or at least it was not for me. There are several reasons that might make this choice very legitimate, starting from a design standpoint, arguing that entity beans are an OO view of the data; therefore they might know nothing about the transactions surrounding them. Another reason may also be the fact that if entity beans will be allowed to demarcate transaction boundaries in an arbitrary way, then things will become far too complex (imagine bean reuse, caching pooling, etc within this context). There is one more scenario that I�d like you to consider: imagine that an entity bean can start/stop its own transaction. Now considering that entity beans are also re-entrant, it might be possible for a client to start a transaction, calling bean A, which calls bean B that calls bean A again. Now if A could independently start its own transaction you might face the situation where the client is initiating a nested transaction. But J2EE doesn�t support nested transaction either ... Regards.
of course there is a way you can use bean-managed transactions and entity beans - you can simply use the JTA APIs to demarcate the transaction boundaries within a session bean that then calls the entity bean(s), and passes it's transaction context.
...but I gues this wasn't the question ;-)
Dave Clark<br />Senior WebSphere Architect<br /><a href="http://www.versant.com" target="_blank" rel="nofollow">Versant Open Access - JDO2 & EJB3</a>
You learn how to close your eyes and tell yourself "this just isn't really happening to me." Tiny ad: