<snip>
>
> 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.
>
You have hit it on the head. I have a current business problem where I have
to go out to 2 legacy systems (mainframes) and a database to perform one
transaction. I have enough information for all these 3 acts to be totally
independent of each other. Currently with the EJB model, I am juggling
around with JMS queues and doing tap dances to extract max. performance out
of the model to solve my business problem.
<snip>
>
> 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.
>
But the container is already threading to maintain its bean pool etc.. That
is the only way CTM's can give you the performance you want. What we are
asking for is the ability to share those container resources to solve a
business problem.
In today's age of clustered and multi-processor architectures, I can assure
you that running out of resources is not a very immediate concern.
As in my example above, the turnaround time to the mainframe is 300-400ms
for the best case. If I was to use traditional architecture and do it all
serially, I am stuck with >1sec response time just for this transaction,
even before I get all the data back to the client. With threading, my
command line example does this in under 50% of the same time.
<snip>
>
> 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.
>
Yes, JMS can solve some problems, but is not the solution for every one of
them. Without the EJB2.0 spec where hopefully a message consumer bean is
present, it is difficult to implement a complete solution.
-- Aravind
===========================================================================
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".
