Rickard �berg wrote:
> On Sun, 5 Mar 2000 19:44:16 -0500, Charlie Alfred <[EMAIL PROTECTED]> wrote:
> >One example of this type would be a service to find airline reservations
> >(or hotels, car rentals, etc.). The client's request specifies a set of
> <snip>
>
>
> > a) to issue 'n' asynchronous requests,
> > b) waiting for them all to return, or for a timeout limit to be reached.
> >
> >JMS provides a solution for part (a). However, the EJB spec precludes the
> >session bean from blocking on the completion of the set of async requests, or
> >the expiration of the timer.
>
>I can't see any reason why a session bean cannot do b). The way I understand it
>a session bean could easily do the following:
>1. Get X nr of JMS queues/topics
>2. Send messages to the queues/topics
>3. Do receive() on each of the X queues/topics
>4. Compute result and return once all receive()'s have completed
>
>Why do you say this is not possible?
>
>/Rickard
What you say is true, MessageConsumer supports synchronous message
receipt (with indefinite, time-limited, or immediate overloadings). Scalability
can get tricky, depending on:
a) how many enterprise beans want to access JMS at the same time.
In the airline reservation example, it could easily be in the thousands.
b) how many different request servers could be hit, this number might
be in the hundreds,
c) how many concurrent requests must be issued by an enterprise bean
to satisfy a single method invocation. Say on average that each
invocation generates requests for 25% of the servers.
JMS 1.02 says "A JMS Session is a single-threaded context for producing and
consuming messages. There are no restrictions on the number of threads that
can use a Session object or those it creates. The restriction is that the resources
of a Session should not be used concurrently by multiple threads. It is up to the
user to insure that this concurrency restriction is met. "
The implication of this is that each enterprise bean instance must have a dedicated
JMS Session (and associated MessageProducer and MessageConsumer).
Unfortunately, I don't see any way to pool these resources in the JMS spec,
and there's no way to do it inside of EJB without synchronization support.
Similarly, the management of Queues becomes a bit of a problem. If we use
a pair of Queues for each request service, then we have the problem of matching
messages written to those queues back to the enterprise beans that are waiting
for them. JMS Message Selectors provide the most generic way to handle this.
However, I have concerns about how a generic mechanism like this will scale
when there are large numbers of synchronous receive operations posted for
each queue. Seems to me like we're talking about a linear scan, evaluating an
arbitrary selector expression, for each arriving message. Or is there a better
way to do this that I'm missing?
Don't get me wrong. I'm a big fan of JMS, and I think it solves a lot of
important problems. I'm just concerned that what it is *not* is a general
purpose solution to parallel operations that require a lightweight coordination
mechanism.
Charlie
===========================================================================
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".
