Viktor Sadovnikov

Hi,

Just an interesting question. "Good" clients of statefull session beans are supposed to call the beans' remove() method. But what to do if the client is also a bean? So the client runs a global transaction and the statefull session beans participate in the same transaction: their are created and do their job within the same transaction. Can the bean-client call remove()?
I tried in WebSphere and received com.ibm.ejs.container.BeanNotReentrantException: TX_METHOD_READY: wrong transaction
Can the bean-client remove statefull session beans? When? Where?

In other words, can a bean, which has participated in still running transaction be removed? If not, when the remove() should be called?

Thank you,
Viktor

Let me refrase the question:
Can the bean, which is involved in currently running transaction, be removed?

Thanks,
Viktor

Hi,

Just an interesting question. "Good" clients of statefull session beans are supposed to call the beans' remove() method. But what to do if the client is also a bean? So the client runs a global transaction and the statefull session beans participate in the same transaction: their are created and do their job within the same transaction. Can the bean-client call remove()?
I tried in WebSphere and received com.ibm.ejs.container.BeanNotReentrantException: TX_METHOD_READY: wrong transaction
Can the bean-client remove statefull session beans? When? Where?

Thank you,
Viktor

Hi,

After the mock exam in Head First EJB, the real exam was easy. I missed 7 question, but one grag-and-drop question I simply could not answer due to "Out of system resource" the application was given. To recover from the system failure I even had to change the computer.

I had some try-and-error experience with EJBs, so for the preparation I only went through the Head First EJB. I guess the point is to understand reasons for every element in EJB architecture and dependencies among them. The SCBCD forum is a great help as well as HFE errata pages on the o'Relly site.

Good luck,
Viktor

Hi,

If container decides to use commit option A (entity stays locked), then it does not invoke ejbStore() after the transactions is commited. It also does not invoke ejbLoad() before the next business method, which runs in a new transaction. These two methods (transactions) can be run by different clients.
Any ideas why EntityContext can be used in ejbLoad() and ejbStore() to get security information about THE client? These methods do not look like directly connect to the clients' calls.

Regards,
Viktor

Hi,

The Coffee Cram after chapter 5 in HeadFirst has a question about getting reference to remote component interface of an entity bean. One of the correct answers is "Receive the reference as a parameter in a method call", which is confirmed by EJB specs on page 119. But I just simply refuse to understand what methods is this about. Do you have any ideas?

Thanks, Viktor

Hi,
I've just e-mailed Dutch SUN Education ses_nl@sun.com and asked how to apply for SCBCD. The procedure is absolutely the same as application of Java Programmer exam.
You send them an e-mail with your name and postal address; they reply with the bank account number; you transfer money; they send you voucher
With regards,
Viktor

Dale,
Do you have an answer on your question?
Regards,
Viktor

I'm quite sure that the Pool Puzzle Solution in HFE book, page 515 is not correct.
The sequence
ut.begin();
c.cmtRequiresNew();
c.cmtMandatory();
c.cmtRequiresNew();
ut.commit()
will result in exception at attempt to call the second cmtRequiresNew(). It would mean that the session bean keeps pending changes from cmtMandatory() (that transaction is not over yet) and is asked to start new transaction. As I understand, it will not work, definitely with statefull session beans.
Can anyone comment on this?
Regards, Viktor

Hi,
ejbCreate() method is indead optional for session beans. The home interface of the stateful session beans is not requried to include create() method. This interface can include "create", which takes different set of parameter, which will result in ejbCreate(parameters) in the bean class.
In short, ejbCreate() method is not checked by compiler. Container generate its name based on methdos found in the home interface.
Regards, Viktor

Hi,
"All possible bean things" are allowed in BMT stateful session beans only. But when you use BMT, you are not allowed to use get/setRollbackOnly(). Instead you can call commit() or rollback()
Regards,Viktor

Hi,
The EJB 2.0 specs state

A message-driven bean instance has no state for a specific client. However, the instance variables of the
message-driven bean instance can contain state across the handling of client messages. Examples of
such state include an open database connection and an object reference to an EJB object.

The table with allowed operations in the same specs tells that "Enterprise bean access" is possible from onMessage() only. Do you know how and when to get the reference to a session bean object and keep during the MDB life-time?
Thanks, Viktor

Hi Rashmi,
I'm glad your understanding of the passivation completely matches with mine But I still do not see a point in getting UserTransaction object

But when tx is completed , and it comes to ejbPassivate , it can always get access to the UserTransaction object

I read UserTransaction SessionContext#getUserTransaction() API and did not anything about getting UserTransaction, where there is no transaction, and what you can do with this. The bean is being passivated, all transactions are done, clients forgot to call remove() and went to bed. On which transaction reference the bean will call methods?
Regards, Viktor

Hi,
Pages 206-07 in HFE are dedicated to passivation of BMT stateful session beans. One page states: "A stateful session bean will NEVER be passivated while the bean is still in a transaction!". On the other page you see that one of the things the BMT bean can do in ejbPassivate() is to "get a transaction reference, and call methods on it".
How does the bean come to ejbPassivate() if it has a transaction? Is there anything I miss here?
Thanks, Viktor

Hi,
I am a bit lost here. "You can have both a Remote and local client view for a bean". To get a reference to a home clients does something like Object o = new InitialContext().lookup("jndiBeanName"); and than has to either narrow-cast or cast to EJBHome or EJBLocalHome. How does container know what type of home the client needs?
Thanks