1.Entity Bean always have to be CMT. Why can't they be BMT?? 2.Consider the following scenario: 2.1.A BMT Session bean starts a trancation and calls a CMT session beans method which is marked with "reqd" tx attribute. 2.2.The called method of CMT bean calls setRollBackOnly() on EJBContext. 2.3.The called method of CMT bean returns. 2.4.Now in the BMT beans method which is resume tx is committed. 2.5.What would happen?(would it throw illegalstate?)
I have chenged my name to real one. Actually I am a starter to SCBCD preparation and thought of my question to be to trivial,obviuos or foolish. Hence thought of a duplicate name. Atleast now can expect some ansers for this?
Hey Tejas, Never think think that way. No question can be considered to be silly. If that's the case, one can say that the exam is full of silly questions In fact your question in a genuine one, I have a real doubt whether the transaction will be rolled back or an IllegalStateException would be thrown. I think the transaction would be rolled back, based on my understanding of the Head First EJB, not 100% sure though
Well, there won't be an exception, as far as I understand your problem: The CMT-bean method has the "required"-attribute, not "mandatory". So if there is no transaction when the method is called, a new transaction will be established. When the methodcall returns in the BMT-bean the BMT is resumed and has no knowledge of the CMT, especially if it's rolledback or not. Remember: BMT-beans do not call SessionContext.getRollbackOnly(). So this transaction may commit or not, it is not dependend on the state of the transaction of the CMT-bean that is closed when the CMT-method returns.
Joined: Nov 21, 2005
No the point is the transaction which the BMT bean started has been set to roll back by CMT bean. Now when the BMT bean tries to ccommit the same transaction what would happen? Also some answers invited for my first doubt please.
Joined: Aug 26, 2001
Thanks for changing your display name. Remember that asking a question might make you look dumb for a moment, but if you don't ask it you might look dumb for the eternity. Your call
1.Entity Bean always have to be CMT. Why can't they be BMT??
Remember that entity beans are abstract classes that usually map a table in a database and that provide abstract get/set methods for accessing the column values in that table. When you deploy an entity bean, the application server will create a new class that extends your entity bean and that provides a concrete implementation for all your abstract methods. The bean-managed transaction model requires you to use a UserTransaction object in order to delimit the transactions in your code. Since entity beans are abstract (i.e., they don't have any code), you will not be able to use UserTransaction anywhere in an entity bean. Hence, the BMT model is de facto not available for entity beans.
2.Consider the following scenario: 2.1.A BMT Session bean starts a trancation and calls a CMT session beans method which is marked with "reqd" tx attribute. 2.2.The called method of CMT bean calls setRollBackOnly() on EJBContext. 2.3.The called method of CMT bean returns. 2.4.Now in the BMT beans method which is resume tx is committed. 2.5.What would happen?(would it throw illegalstate?)
I usually don't like to answer questions like these because it would be much better that you actually go ahead and write some code for visualizing the scenario and see what happens. Remember that EJBs (as well as many other technical topics for that matter) cannot be learned theoritically. You have to put your hands in the dirt in order to see how it works. This is the only sustainable way of learning EJBs. Writing and deploying code for the above scenario wouldn't take much longer than a couple of minutes.
Now, an answer to your question can be found in section 17.2.4 (Client-managed demarcation) of in the EJB 2.1 spec which states:
The application programmer demarcates the transaction with begin and commit calls. If the enterprise beans X and Y are configured to use a client transaction (i.e., their methods have either the Required, Mandatory, or Supports transaction attribute), the EJB server ensures that the updates to databases A and B are made as part of the client�s transaction.
In your case, you don't have two databases, but the same logic applies, namely a BMT bean calling a CMT bean.
Write some code and see for yourself. Please let us know the outcome so that others can learn from your experience...
Brain power !!! If you answer the following questions, you will know why entity bean transactions are always managed by Container: Who is responsible for calling ejbLoad/ejbStore ? Under which circumstances will ejbLoad/ejbStore triggered ?
Joined: Jan 09, 2005
Originally posted by Tejas Gokhale: 1.Entity Bean always have to be CMT. Why can't they be BMT??
Nadeem, I read your thread, I am not sure I got it. In a BMP bean, you are going to write the database access code in ejbLoad() and ejbStore(). But it is the container that's going to call these methods. Why can't you put a ut.begin() and ut.commit() in ejbLoad() and ejbStore()? I understand there would not be any specific advantage doing that, but it should be technically possible and does not affect any of the persistence features of the container right?
I think the real reason for this is to just keep things consistent for both CMP and BMP. It is possible to have BMT for BMP beans as you are coding the ejbLoad and ejbStore methods, but you cannot do that in CMP beans, because the database access code in these methods is written by the container, but the spec designers just wanted to keep things consistent for both CMP and BMP and hence they disallowed it in BMP beans as well. That's my take.