Article:		Understanding Classloaders: log4j in a J2EE Environment
Subject:		threads in EJB ?
Date:		2003-04-16 05:16:47
From:		anonymous2
I am using Log4J in my EJB as per your article. Well now i have a serious issue that EJB specs says not to use threads but Log4J use thread to log into file system. So log4j is it not violating the specs when used inside my EJB ? plaese reply to me to my mail id srinath@dwp.net regards Sreenath.V

Showing messages 1 through 2 of 2.

• threads in EJB ?
  2003-11-16 21:35:22  anonymous2 [View]
  
  
  u mean to say the container handles the threading concepts for the iterations in the process.

• threads in EJB ?
  2003-06-18 09:04:22  bclayabt [View]
  
  
  The issue of threads as they relate to EJB’s can be confusing. Actually, the specification reads: The enterprise bean must not attempt to manage threads…. It would be impossible to guarantee that every 3rd party library an application utilizes does no thread management. The spirit of this restriction boils down to two issues: risks of reentrancy, and the container’s overall ability to control the runtime environment. If an EJB creates a thread, and that thread executes code that results in the creation of other EJB instances, or passes through code that the container expects to have full control over, it can (and probably will) compromise the container’s ability to manage concurrency issues and other things. This is a form of reentrancy.
  
  Secondarily, when a thread is spawned, the container has no way of terminating the thread and/or freeing the resources held by that thread when it chooses to passivate or remove an EJB. The argument could be made that the lifecycle methods could be used to manage the thread, but there is almost always a better solution to the underlying problem that the application is trying to solve. Specifically, solutions that press the envelope on threading in this way can often be better solved using some sort of JCA approach to manage the resource they would otherwise attempt to manage using the thread.
  
  When it comes to Log4J and other libraries that utilize threads to perform internal housekeeping, my experience has been that they pose no problems. These threads don’t touch any other runtime artifacts that could introduce reentrancy, and they don’t compromise the container’s ability to manage the runtime environment.