Discussions

EJB programming & troubleshooting: OC4J Issues

  1. OC4J Issues (3 messages)

    I am working with OC4J (nee Orion) and have found 2 really weird things going on involving EJBExceptions, and I was hoping someone else had run into these issues and could help me.

    1) I thought that throwing an EJBExeption from a stateless session bean method in a Required transaction context was enough to roll back the transaction (and kill the bean instance). Calling SessionContext.setRollbackOnly() shouldn't be necessary. I have tried both approaches (just throwing EJBException and calling SessionContext.setRollbackOnly() when an exception is thrown), yet in both cases any database changes that have been made are not rolled back. Do I have to explicitly place the entity beans involved in a transaction context as well even if their methods are ultimately called by the session bean in question? I thought the transaction context just propagated all the way through....

    2) I thought that when an EJB exception is thrown at the bean level, the client should receive a RemoteException (whose Throwable detail member contains the details of what happened). However, my test client is receiving a null.

    For example, assume I have TestBean, TestHome, and Test, and Test (and TestBean of course) has a method called foo (original I know). The client uses TestHome.create() to get an instance of Test. He then does something akin to
             
                     Object o = Test.foo();

    but TestBean.foo() throws an EJBException. I assumed that the client would receive a RemoteException in this case, but instead in my application foo() returns null. Thus any calls on the o reference throws a NullPointerException. Can anyone explain this?

    I assume both these problems can be fixed by configuring something in one of OC4J's several deployment descriptors. If someone could let me know where and how to edit them, I would be very appreciative.

    Thanks.

    Threaded Messages (3)

  2. OC4J Issues[ Go to top ]

    1) I thought that throwing an EJBExeption from a stateless session bean method in a Required transaction context was enough to roll back the transaction (and kill the bean instance).

    A) A few things. First off, what transaction settings does your method have? Yes tx context will propogate but only if you set the appropriate tx settings on every method.

    B) Not every exception will cause a rollback. Only SYSTEM level exceptions like EJBException, RemoteException and RuntimeExceptions will. Exceptions are an unpredictable way to control tx. You should use setRollbackOnly() if you can. A SYSTEM Exception is like the EJB version of a GPF. It should only happen in unpredictable circumstances.


    2) I thought that when an EJB exception is thrown at the bean level, the client should receive a RemoteException (whose Throwable detail member contains the details of what happened). However, my test client is receiving a null.


    A) Nope. Not guaranteed. The reason is very long and ugly and has to do with RMI over IIOP and IDL bindings. But in short, the message field is lost on EJBException and RemoteException. If you need a message field use an APPLICATION Exception.

    Dave Wolf
    The Scupper Group
    dave at scuppergroup dot com
  3. OC4J Issues[ Go to top ]

    Thanks for responding, Dave.

    In Point 1A, you seem to suggest that I need to provide a transaction setting on every method called by my primary business method (which already has a Required transaction setting) in order for propagation to occur. That was my next step, and I will try it.

    In Point 1B, you mention something that I already knew. However, that primary business method described above does throw an EJBException (which as you know sublasses RuntimeException and should therefore abort a transaction). Could you offer further clarification on why this doesn't happen this way? Could it have something to with the point in 1A?

    Finally, with regards to point 2A, it may have appeared that the messaging of the exception was what I was concerned with. That is secondary. My primary concern by far is allowing the client to see that an exception occurred from his method call rather than getting a null back. After all, the method could run perfectly and simply return null. This circumstance needs to be differentiated from that in which the method call throws an exception. Is there no way to make this happen in a portable manner?

    Thanks again.



  4. OC4J Issues[ Go to top ]

    1A) Yes give that a try.
    1B) Interesting, likely caused because work in the other methods occured outside a tx? Not sure until we dig into this more
    2) Now yes thats bad. They should get the Exception propogated to them. I thought you meant the message field in the Exception didnt marshall.

    Dave Wolf
    The Scupper Group
    dave@scuppergroup.com