Killing external processes initiated by EJB

Discussions

EJB design: Killing external processes initiated by EJB

  1. Hi there--

    We are designing a J2EE system that will integrate with 3rd party software. We plan to execute our business logic using EJBs, and then issue calls to third party software as required. Since the calls will be issued from EJBs, we cannot use primitive multi-threading techniques. We've considered using JMS in some cases, but that still does not address our main issue.

    The main problem is that we are unable to kill the external process if something goes very wrong. This is something that we could implement with multi-threading (interrupt or stop the thread, if necessary) -- but we don't know how to get around that in a J2EE environment.

    Any thoughts?

    Thanks,
    elize
  2. The spec says that your bean may not use the synchronized key word. It does not say that the classes your bean calls cannot do things with threads.

    If you look at all the EJB samples, they have beans which contain Hashtable and Vector. They call methods on these classes. All methods on these classes are synchronized, QED. :-)

    So, put your logic in a support class and call it from the bean.

    Things you need to consider are:

    1) Make sure that, one way or the other, your threads die in a predictable amount of time. You are taking away control of resources from the container when you create threads. If you take away control, then it's your responsibility now.

    2) You don't rely on server affinity or any other cross-VM mechanisms in your multi-threading design. In other words, you can't stop server A from running a program inside a bean if server B is already doing so.

    Actually, that's a bit strong. You can do (2) but it is not particularly good fun. :-)

    Chz

    Tony
  3. <q>
    The spec says that your bean may not use the synchronized key word. It does not say that the classes your bean calls cannot do things with threads.
    </q>
    Disagree, the rule applies to bean and any help classes it
    calls.

    <q>
    This is something that we could implement with multi-threading (interrupt or stop the thread, if necessary)
    </q>
    Such operations are problematic even for standalone Java programs not mention doing that inside the EJB container.

    You had better create an external application to do all
    these stuff, then your bean communicate with it through RMI/CORBA/JMS ..etc..depend on your requirements.





  4. <q>
    The spec says that your bean may not use the synchronized key word. It does not say that the classes your bean calls cannot do things with threads.
    </q>
    Disagree, the rule applies to bean and any help classes it
    calls.

    If your statement is true then most of the example EJB classes that come with most servers are non compliant with the spec.

    Chz

    Tony
  5. Then I am afraid they are not.

    Think about it..it really doesn't matter if you synchronize in the bean class or in the helper class..as long as it is in the same thread of control, you may got into trouble.

    BTW...there are non synchronized version of hashtable and
    vector..why not use that?
  6. I completely agree, that the semantics of where you put the synchronization are irrelevant. Somewhere along the lines, you start controlling threads.

    However, I believe it is commonly accepted that people do use synchronized code in helper classes; mostly when using caches. I know these are theoretically outside the spirit of EJB, but until it provides a way to support them itself there isn't an awful lot of choice.

    For instance, there is another discussion on this site which talks about someone who is passing a Hashtable as an argument to an EJB. Theoretically that's against the spec if the bean calls any methods on it. In practice, it probably makes no difference at all.

    Isn't this stuff fun! :-)

    Chz

    Tony
  7. But allowing use synchronized is like opening pandora's
    box. Hashtable is a special case, the algorthim is well
    known, the lock is short and "fine grained", so you can
    be sure that you will never run into deadlock or starvation by using hashtable.... most of the time, that is not case..
    I can't agree more with the EJB spec: it is not proper to put such burden on the developers..