There was some early discussion of having EJB containers provide a
thread creation service; however, there were many unresolved issues with
this concept. This would be a more natural fit than inventing some form
of async method call semantics.
It would likely take a significant demand from customers before such
functionality would make the A list for a future version of EJB.
Aravind Naidu wrote:
>
> 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".
===========================================================================
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".
