Example one:
The JTA API allows you to associate a transaction with any thread, and
to share the same transaction context with multiple threads. But EJB
does not expose that portion of the JTA API (TransactionManager), so you
have no way of running a transaction within a thread.
You can, however, use a JDBC connection opened from the main thread (the
method call) in the secondary thread (that you created). As long as the
method is still running, that connection will be available. Once that
method has completed, your transaction may commit/rollback without any
consideration for the second thread that might still be using it. Worse,
the connection can (should) be closed, so your second thread will now
throw an SQLException.
Example two:
The EJB server exerts security control over bean method calls. This
system breaks when you start using thread. A method call on behalf of
'John' may open a thread, which 'Betty' can use, although 'Betty' has no
privilege to perform the same operations that 'John' can.
Example three:
The EJB server may decide at any point to terminate a running thread
(e.g. after determining it's an infinite loop), to reload all the
classes using a separate class loader, to move your bean instances to a
different server, etc. That would leave your threads hanging high and
dry.
What all that means is that if you do want to use thread in a safe,
secure, reliable manner, the three solutions that will work best are:
1. Use JMS for asynchronous stuff first, think of threads second
2. Some stuff belongs in a resource manager (or connector) as an outside
library, not in your EJB code. That stuff is better aware of the
threading requirements and does not take EJB container contracts for
granted like your bean do.
3. EJB can use a thread-capable API, allowing you to work with threads
in an EJB-aware manner
No. 3 is not as trivial as it sounds.
arkin
dan benanav wrote:
>
> 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".
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
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".
