Could someone interested in this threading issue offer a specific
example of one of the problems that require threading beans to
solve? I think it might be helpful to consider the problem in more
concrete terms.
The "parallel workflow" example, for instance, seems very general.
You probably wouldn't map tasks to bean threads if the tasks were
long-running (e.g. required user interaction), because of the
problems inherent in managing server resources.
Maybe the idea is to respond more quickly in the context of a
single method call with three independent tasks? For instance, the
method returns true if independent conditions a, b, and c all return
true, and response time would be the sum of processing times for
a, b, and c under a single-threaded model. Under a multi-threaded
model, the response time would probably be between that and the
longest of a, b, or c.
Of course, cases might exist where this is necessary. But it
seems to me there are trade-offs in terms of bean complexity and
server complexity. And consider this: would it be possible to
achieve the effect you are looking for some other way? (If this is
indeed a generalization of what you are looking for.)
In general, you would be trading user-response time for through-put
in the case where you used threads to solve a, b, and c in parallel.
Those threads (presumably out of a thread pool) would be claiming
additional slices of processor time/database resources/whatever to
work on the problem that would be available to service other
requests. If there is no scarcity of resources, then you need
threading to duplicate this response time. But if there is scarcity,
then it seems to me you are just--in effect--boosting the priority of
your request in your code. You get additional slices of the
processor's time; you get additional connections to the database.
And this would have to come at the expense of other requests
(assuming scarcity.) And the overhead of the threading would
probably reduce overall efficiency.
Maybe a declarative solution involving priorities would be a possible
solution. A method's "priority" could be specified in the
deployment descriptor, and the container could enforce it by
interposing on connections, adjusting thread priorities, etc.
At the point where the tasks are long enough to make threads and
simultaneous connections worthwhile (three independent tasks that
each involve a two-minute SQL query) the overhead of a JMS
solution doesn't seem that terrible.
I suspect I'm missing the point... but that brings me back to my
original request. Can someone offer a specific concrete example
for us to talk about?
-Dan
On 3 Mar 00, at 16:14, Assaf Arkin wrote:
> > Absolutely. I second the motion. I particularly endorse an API that
> > treats thread creation as its own thing, and doesn't try to make it
> > conform to more generic constraints. Threads are unique.
>
> Mark is on this list, so maybe he would like to open up a JSR for
> specifying thread beans.
>
> > And no, I don't believe that the answer is just "use JMS wherever you'd
> > use a thread". That solves some problems, but not all of them.
>
> I totally second you on that. JMS is ultra useful, but just doesn't
> solve the problems you're dealing with (nor many other developers on
> this list).
>
> Any ThreadBean JSR on the horizon?
>
> arkin
>
> >
> > 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".
>
> --
> ----------------------------------------------------------------------
> 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".
>
===========================================================================
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".
