I have been reading this Threads question thread and I still don't completely
understand why creation of threads would damage the container's "management" of
threads and resources and why it is restricted. I understand somewhat why it
is usually a bad idea to spawn threads in method calls (see below) but maybe
there are circumstances in which it is not bad It would be very helpful if
someone could give a very concrete example of why the spawning of threads is
not good. I keep hearing things like "a container needs to manage threads and
resources". How does it do that? What kinds of things does it do to manage
threads? What damage would be done if I create a thread? Please be as specific
as you can and give concrete examples of what the container does to manage
threads.
I think I understand that if one creates a thread anything that happens in that
thread will not occur within the transaction context. So it is probably a bad
idea to use threads. For example suppose that I have a been that enters a new
order into the database using a method called order(Item i). Suppose also that
when the order is created a mail is sent to Mr X. I might be tempted to use
the mail api within the order method of the bean instance to send mail to Mr.
X. But that would be bad practice because it is possible the order may be
rolled back if there is an exception generated during the call to ejbStore. So
if for example you do the following,
public void order(Item x){
//do whatever
MailSenderThread sender = new MailSenderThread(Item).start();
}
You might end up sending mail even though the order was never successfully
placed. The order entry into the db may fail in ejbStore.
You could write MailSenderThread to get is own connection and check the
database periodically waiting for the order to be entered into the db. But if
the transaction rolls back you will have a dangling thread that is holding a
connection resource. So that looks like a bad idea also.
One could use a stateless session bean for this. In the afterCompletion method
for the session bean start your mail thread. (That is OK because it is not a
business method).
So this is a bad use of thread creation. In general threads do things and you
may not want it to do something if the transaction fails or rollsback.
Dangling threads could be created if you aren't careful. It's not easy to
think of a case that this doesn't apply to. What about this? Suppose I want
to determine how long it takes from the time an order is placed until it is
committed to the database. So instead of the above I do something like:
public void order(Item x){
MyTimerThread myTimer = new MyTimerThread(x).start();
//do blah blah
}
Now I write the timer thread to wait for up to x minutes and die after that.
It checks the database a commit of the order and records the time from
placement of the order until it succeeds.
I understand there are other better ways to do that but what damage would it do
to the containers managing of threads? Please be specific about how containers
do that.
dan
Laird Nelson wrote:
> An enterprise bean may not use thread primitives. I take this to mean
> it cannot do this:
>
> Thread t = new Thread(someRunnable);
> t.start();
>
> ...or this:
>
> synchronized (someGuard) {
> doCriticalWork();
> doMoreCriticalWork();
> }
>
> ...or this:
>
> Thread t = new Thread(someRunnable);
> t.start();
> t.join();
>
> ...but the specification seems to imply that it COULD do something like
> this--and I hope I can:
>
> ThreadDelegate td =
> new BasicJavaObjectThatUsesThreadsAndSynchronizationInternally();
> td.doWork(); // implementation works with threads
>
> Is this true? If for some reason it is NOT true, doesn't this mean I
> now have to know about implementation details of all the plain-Jane Java
> objects my enterprise bean might use? Wouldn't such a thing blow
> reusability out of the water?
>
> If it IS true, then why can't an enterprise bean use threads directly,
> as the invocation of td.doWork() in the example above occurs in the
> enterprise bean's caller's thread anyhow?
>
> Cheers,
> Laird
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
