Dan,
Amazingly enough I have yet seen a clear description of why thread creation is not
allowed nor have any concrete examples been offered.
Dan OConnor wrote:
> 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".
===========================================================================
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".
