Your examples are good ones, and make a compelling argument
about the dangers associated with non-container threads.
In my view, however, they are not compelling enough to assert that
enterprise bean interaction with threads should be precluded.
Some specific comments follow:
> -----Original Message-----
> From: Assaf Arkin [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 23, 2000 11:13 PM
> Subject: Re: Threads question (Concrete examples?)
>
>
> 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.
>
If my neighbor uses a key I gave him to let himself into my house to return
a tool he borrowed, it's possible that I might leave the house while he's inside
and set the security alarm. Sometime later, the motion detector senses his
presense and triggers the alarm. Bad news.
Similarly, if the secondary thread "borrows" a JDBC connection from the
first without its knowledge, bad things can and will happen. A safer approach
is that the first thread (the one that owns the JDBC connection and determines
its lifetime) must be aware of the second. This may require that the first
thread has the ability to synchronize with the second (i.e. wait for it to complete).
>
> 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.
>
Assume that a Java class MT inherits from java.lang.Thread and a singleton
instance of that class runs inside my EJB Server. Because the MTinstance
is accessable from multiple threads, all of its methods are synchronized.
Also assume that I have EJB's that know of MT's existence. When an EJB
method is called, it wants to invoke MT.foo(). What you're saying above is
that the EJB's security context will not be propagated into this call:
a) it may not matter. neither foo() nor anything it calls have
authorization requirements. For example, foo() may be an event
logging mechanism.
b) The EJB method can call javax.ejb.EJBContext.getCallerPrincipal()
to get a reference to the java.security.Principal that made the call
to the EJB. I'm not familiar with the exact mechanics, but I'm sure
there is a way for for a thread to assume the identity of a Principal
that is passed into it, assuming that the thread was setup to have
the proper security priviledges.
>
> 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.
>
This would only occur if the alternate threads were actually running
"inside" the EJB. If the alternate threads are executing run() methods
of Java runnable objects that are outside of the EJB container/bean
partnership, things are significantly safer. In this case, the risk is about
the same as it would be for ordinary EJB clients (i.e. what's to prevent
the EJB server from killing a thread before it returns results to a client).
>
> 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
>
As I mentioned in a prior post, the JMS spec asserts a requirement for
serialization (e.g. on Session objects) without specifying the means to
ensure this. One JMS provider may decide to implement thread-safe
sessions, thereby allowing several EJB instances to try to post messages
concurrently. Other JMS providers may leave this up to the callers to
serialize their own calls to the JMS session.
> 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.
>
Resource Managers and Connectors will be welcome additions to the J2EE
platform, once their specs are approved and vendors implement support
for them (not until EJB 2.0, at the earliest, as I understand). Many of the
capabilities that people have wanted to implement in this thread would be
best done by implementing a Resource Manager (capable of participating
in en EJB transaction) or Connector (capable of interacting with non-EJB
components like CORBA, ERP, etc.).
In the meantime, application requirements for these sorts of capabilities
aren't going to go on hiatus. That's one reason that the "caveat emptor"
philosophy of some vendors is greatly appreciated. I'd much rather have
an EJB server vendor warn me about the limitations and risks of certain
actions, then tell me they won't let me do it for my own good.
> 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
>
As someone who still has the 3rd degree burn scars from prior work with
multi-threading, I couldn't agree more. On the other hand, once you learn
your lessons properly, it opens up lots of horizons. Flying a helicopter is
more difficult and more dangerous than flying a car, but its also faster and
allows you to reach a lot more places.
Charlie Alfred
Foliage Software Systems, Inc
===========================================================================
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".
