That's a pretty darn good example. Thanks.
-Dan
On 5 Mar 00, at 19:44, Charlie Alfred wrote:
> 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.
> >
>
> 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
> constraints and an objective function. For example, find reservations
> for 4 passengers from Boston to Orlando, leaving on 4/22/00, returning
> 4/29/00, departing between 11:00 AM and 6:00 PM, with an aircraft
> type that's non an MD-80. Rank the alternatives by giving 50% weight
> to the lowest round trip fare, and 50% weight to the shortest scheduled
> flight time.
>
> The service may be able to use cached information (read-only or read-mostly),
> such as the airlines published schedules to narrow down the field. However,
> some information (such as how many seats are available at which fares) may
> be too volatile to cache. In this case, the service must issue queries to each
> of the vendors that has survived the initial set of filters. Response time is
> reduced greatly if this set of requests can be issued asynchronously.
>
> The client of this service wants to use a synchronous protocol (i.e. it passes in
> its parameters, the service doesn't return until it has the result). If I want
> to implement the service using a Stateless Session Bean, I have the problem
> of figuring out how to:
>
> 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.
>
> As far as I can tell, in order to provide this type of service, I'd need to handle
> the client's request using CORBA or straight RMI. Which, in my view is too bad,
> because I think that this sort of situation is at least as prevalent as the shopping
> cart pattern that motivated Stateful Session Beans. I'd much rather see the
> EJB spec come up with a standard way of handling this.
>
> Charlie Alfred
> Foliage Software Systems
>
> ===========================================================================
> 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".
