Discussions

EJB programming & troubleshooting: EJB and Threads

Bookmark and Share Get thread feed

  1. EJB and Threads (5 messages)

    As per the EJB Spec EJB's should not attempt to play with any threads. I have heard some folks say that this means that any entity like a data access object that the EJB calls should not spawn any threads. Some say that such objects outside of the EJB class can . The line in the specification is as shown below..
    ""
    The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt
    to start, stop, suspend, or resume a thread; or to change a thread’s priority or name. The enterprise
    bean must not attempt to manage thread groups.

    "".

    This seems to be very open ended and is not specific. Any thoughts on what should be the right way of working with threads in a EJB world would be appreciated..


    Reply to this

    Threaded Messages (5)

  2. EJB and Threads[ Go to top ]

    Hi,

    You shouldn't spawn threads in an EJB or in any class that the EJB calls out to. In WLS, for example, the transaction context is associated with the thread. When you spawn a thread, that transaction context is not associated with the spawned thread which makes it useless for any activity that would need to be part of the current transaction.

    I think the spec is pretty clear and I don't know why it should matter whether or not you put the thread creation code in a 'helper' class. That is still called by the ejb. The Container doesn't do something special when you make a call to another class to allow thread creation.

    FWIW, spawning threads in a threaded app server is a bad idea and, imho, is indicative of a design flaw. The app server is already performing thread management for you, which is one of the reasons you use an app server in the first place.

    Bill
    Reply to this Reply to original

  3. EJB and Threads[ Go to top ]

    I have heard people say "Well I am not calling it from the EJB I am calling it from an Object the EJB calls so I am not breaking the rules" or "I am starting the thread in my Servlet not the actual EJB itself". Each time I nearly cry.

    Thread management is part of the J2EE Containers job. It is that simple.

    I think there are so many people that read the rules but don't understand why you should not do certain things from within the container. The spec for every rule states the reason behind the rule. Understand the reason and therefore understand the rule

    "• The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt
    to start, stop, suspend, or resume a thread; or to change a thread’s priority or name. The enterprise
    bean must not attempt to manage thread groups.

    These functions are reserved for the EJB Container. Allowing the enterprise bean to manage threads
    would decrease the Container’s ability to properly manage the runtime environment."


    David
    Reply to this Reply to original

  4. EJB and Threads[ Go to top ]

    From my reading of the SPecification i do feel that threads should not be started. But arent there situations in the real world where you are forced to do so. In a situation where your EJB ends up calling three seperate EJB's one of them calls a mainframe of some sort .There is atleast no context of a spanning transactions when you are talking to a Some mainframes indirectly through an XML API / C API etc.. Then if the process is time consuming you dont want other things to wait.

    I have seen both the scenarios in the real world and hence wanted to see what others are doing out there.

    Reply to this Reply to original

  5. EJB and Threads[ Go to top ]

    This is why JMS exists. If you want a 'logical' thread of control, pass a message to the JMS bus and onto a MDB. This accomplishes the same thing as spawning an async thread and doesnt break the container.

    Dont spawn threads, this is why the container is there. Use it.

    Dave Wolf
    The Scupper Group
    dave@scuppergroup.com
    Reply to this Reply to original

  6. EJB and Threads[ Go to top ]

    These types of problems are best handled by JMS, MDB, and/or WebServices. Tieing up a thread in a long running transaction is the root of the problem, whether you are using J2EE, or not. This type of problem is best addressed by message based asynchronous applications, which is what JMS, MDB, and WebServices give you.

    Bill
    Reply to this Reply to original