| 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 ?
|
||
Showing messages 1 through 2 of 2.
-
threads in EJB ?
2003-06-18 09:04:22 bclayabt [View]
-
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.



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.