I do tend to agree with you that 'threading' at what is a business logic
layer can be fraught with problems. It is a good idea to restrict threading
at the business layer (Having moved some Cobol programmers to do C++ based
threading and the associated problem, I can sympathise).
But at the same time, I would like to have lightweight parallel processing
or async calls without resorting to JMS and its infrastructure.
What about API based asynchronous calls ?
handle = object.getCustomer(custNum); // returns immediately
// Do something else
customerObject = getObject(handle);
Has this been considered ? That way, the container has to implement
asynchronicity and you don't have to expose the threads to the bean
programmer.
The Tuxedo TP monitor did it this way.
-- Aravind
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of MARK HAPNER
> Sent: Tuesday, 21 March 2000 16:08
> To: [EMAIL PROTECTED]
> Subject: Re: jms & ejb
>
>
> 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".
>
>
===========================================================================
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".
