Most people who have used Java threads in the context of middle-tier
business logic have found that they are too complex for most developers
to realiably get right (i.e. most devlopers still don't full understand
the issues and are not able to debug threads). This coupled with the
portability problems caused by their conflict with EJB container
management is the basis for the EJB 1.1 threading restrictions.
The assumption in this discussion is that use of Java threads in an EJB
is a practical mechanism for speeding up the response to a client by
utilizing the parallel computing resources of several external systems.
I believe in many cases this 'optimization' doesn't work too well as
load scales up. There is a cost in complexity and overhead for
introducing asynchrony. The tradeoffs are often counter intuitive.
For instance, in the case of database queries to a single engine it is
quite possible that sending two queries in parallel will run slower or
simply be serialized by the engine.
The more important use for asynch processing in the business world is
for workflow rather than response optimization. JMS is a good fit for
this.
The bottom line is that although 'parallel' processing within a request
is interesting for some special cases, it was not considered by EJB
partners to be of sufficient importance to require all EJB vendors
implement a fully architected solution for it.
If you feel such a facility is needed you should make this known to your
vendors and possibly some future version of EJB will add a requirement
for it.
-- Mark
Aravind Naidu wrote:
>
> The problem with the current specification is that who is going to handle
> the receiver part. This has to be a separate program/legacy system etc.
> etc.. I am told that EJB2.0 will solve this.
>
> Frequent usage of lightweight parallel processing is to do things like SQL
> queries in parallel, access different legacy systems to get disparate data
> etc.
> For all this it would be nice if the spec provides some method of doing
> lightweight parallel processing. On a current system we go out to 3 legacy
> systems. Fortunately, 2 of them are queue based, but one is synchronous and
> thus the response time is always tied to the synchronous one in the absence
> of threading. I could do it using queues, but then it falls out of the EJB
> Server/CTM boundary at the current level of specification.
>
> Doing in JMS is ok, but with the incomplete spec. and also that means that
> there is one more moving cog in the wheel to look after...
>
> We have an application that has to be moved to EJB, that does some very
> complicated calculations, some of which for speed purposes where done in
> parallel in an older TP monitor based architecture. We are stuck with doing
> threading in the client or inventing a convoluted queue based architecture
> to what is simple lightweight parallel processing.
>
> -- Aravind
>
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Rickard �berg
> > Sent: Sunday, 19 March 2000 03:27
> > To: [EMAIL PROTECTED]
> > Subject: Re: jms & ejb
> >
> >
> > > <rant target="not at all chris personally">Oh good grief, if every time
> > > I want to do three or four quick tasks in parallel I have to drag out a
> > > workflow engine, I would go batty.</rant>
> >
> > I'm confused by this. Can you please explain to me what is so bad with
> > using JMS to solve this?
> >
> > Here's some pseudocode I would use to do it (shamelessly copied from Don
> > Fergusons/BEA session at their User Conference. Thanks Don!):
> > InitialContext ctx = new InitialContext(env);
> >
> > Topic topic = (Topic) ctx.lookup("sometopic");
> > TopicConnectionFactory connectionFactory =
> > (TopicConnectionFactory)
> > ctx.lookup("javax.jms.TopicConnectionFactory");
> >
> > TopicConnection connection =
> > connectionFactory.createTopicConnection();
> > TopicSession session = connection.createTopicSession(false,
> > Session.AUTO_ACKNOWLEDGE);
> > TopicPublisher publisher = session.createPublisher(topic);
> >
> > TextMessage message = session.createTextMessage();
> > message.setText(?hello world?);
> > publisher.publish(message);
> >
> > publisher.close();
> > // Message sent; wait for response
> > TopicSubscriber subscriber = session.createSubscriber(topic);
> > connection.start();
> >
> > Message m = subscriber.receive();
> >
> > subscriber.close();
> > session.close();
> > connection.close();
> > -----
> > That wasn't so bad, was it? And you could easily abstract this away with
> > a helper class to:
> > ----
> > Message m = jmsHelper.sendReceive("hello world", "sometopic"); // Send
> > "hello world" to "sometopic" and receive reply
> > ----
> > Now, you've gotta explain to me what's so bad with the above, 'cause I
> > aint getting it.
> >
> > Of course you could expand the above to send to several queues and
> > receive from several queues in order to do parallel processing.
> >
> > What am I missing?
> >
> > /Rickard
> >
> > --
> > Rickard �berg
> >
> > @home: +46 13 177937
> > Email: [EMAIL PROTECTED]
> > http://www.dreambean.com
> > Question reality
> >
> > ==================================================================
> > =========
> > 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".
