• Post Reply Bookmark Topic Watch Topic
  • New Topic

Threads in EJB  RSS feed

 
J Venkatesh
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Is it possible to implement multithreading in
EJB.What is the function of ejbPassivate() in
Session(Stateless & Stateful) and Entity(CMP & BMP)beans.
regds
j venkatesh.
 
Mat Robinson
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Multithreading is not allowed within EJB's, this is a restriction for the Bean Provider in the specification. The reason for this is that the application server must be able to control the threads and optimise itself.
As for your second question, ejbPassivate() and ejbActivate() are callbacks used by the application server to serialize the object.
In other words, the server can at any time remove the bean instance you are currently working with from the bean pool. If this happens the server will passivate the bean, during this phase the app server will call the ejbPassivate() of the bean instance. This is your cue to ditch anything that is a system resource or the like, that is not serializable. The bean, can then be used by someone else. The ejbActivate() is the reverse, when the application server gets your bean back again, for instance when you need to use it, then it will call ejbActivate(), you then pick up all the stuff you ditched in the passivate phase.
For a fuller explanation, I would refer to Mastering Enterprise JavaBeans by Ed Roman. (A PDF can be found at: www.theserverside.com
I hope this helps,
Mat.
[ August 06, 2002: Message edited by: Mat Robinson ]
 
Karthik Guru
Ranch Hand
Posts: 1209
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
yeah it's not advisable but it's upto the container vendor i guess whether he allows u to do that or not.
I c'd do it with weblogic6.1 and it did'nt complain.
Originally posted by J Venkatesh:
Hi,
Is it possible to implement multithreading in
EJB.What is the function of ejbPassivate() in
Session(Stateless & Stateful) and Entity(CMP & BMP)beans.
regds
j venkatesh.
 
Peter Reinhardt
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by karthik Guru:
yeah it's not advisable but it's upto the container vendor i guess whether he allows u to do that or not.
I c'd do it with weblogic6.1 and it did'nt complain.

NOT TRUE. the spec doesn't allow it at all (for all J2EE compliant application servers). The fact that you are able to do it, does not mean that it is advisable to do so (or that the vendor allows it).
Among multi threading other stuff like file descriptors, serversockets, classloading, JNI etc. are FORBIDDEN.
the reason for this is basically that the container knows best how to handle these resources and the bean provider should not be bothered (and endanger the stability of the container).
[ August 06, 2002: Message edited by: Peter Reinhardt ]
 
Karthik Guru
Ranch Hand
Posts: 1209
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Peter Reinhardt:

NOT TRUE. the spec doesn't allow it at all (for all J2EE compliant application servers). The fact that you are able to do it, does not mean that it is advisable to do so (or that the vendor allows it).
Reinhardt ]

I infact said that it is not advisable!
am surprised that you are quoting me the other way around.
I managed to start a thread in weblogic6.1 (sp3) from within a stateless session bean and obviously wrote some code in the run() and saw it working.
am not sure if weblogic6.1 is j2ee certified :-)
I can send in the code that ran for me if u want me to.
BTW, which app server are you using? have you tried creating a thread in your bean?
karthik
 
Peter Kristensson
Ranch Hand
Posts: 118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It doesn't really matter if the app server forbids threads or not.
It clearly says in the spec that EJB:s are not to create threads.
And if you, as a bean provider, decide to sidestep from this, you're on your own, and can never rely on your bean to run on ANY appserver, since the appserver might later on implement protection against threading.
On the other hand, if you implement your bean with all the neccesary interfaces and whatnots, you're guaranteed that it can be run on a J2EE-compliant server.
There's no need for this discussion really, just never start threads.
 
sim sim
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Peter,
The following is an extract from EJB 2.0 Spec.
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.
It says that thread management can be done but not advisable as it will decrese the efficiency of the app server.
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK, what seems to be missing here is WHY you don't want to start threads. Here's the scoop. In every app server that I know of, transaction contexts are associated with threads. So if you start a thread within your bean, it is unknown to the container, and it is not associated with a txn context. Thus if you attempt to do anything in that thread, and it causes an exception, it will not affect the transaction associated with the original (starting) thread. Likewise, if you attempt to modify a database resource (through an Entity bean, or a JDBC connection) in the new thread it will NOT be part of the transaction that is in the other thread.
Because of this complexity (which, by the way, applies for security contexts as well) you shouldn't do multithreading in EJB's. If you don't need transactions, and don't need security, then you COULD do threads in your EJB's -- after all, as has been stated earlier, the container won't actively keep you from doing it. But my contention is, why would you be doing EJB's in the first place if this is true?
Kyle
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!