We also have a requirement to cancel an asynchronous request. It is a query tool, and users will be able to cancel queries once they have already started running. MDB seemed like the ideal choice for submitting queries asynchronously, but I think this requirement of being able to cancel a running query seems to spoil it. Or,does anyone know how we could/should still do MDB?
Thanks, Mike --- Nicholas <[EMAIL PROTECTED]> wrote: > I do not know of any specific MDB perfomance issues. > Can you elaborate ? > > Also, technically, if the message has been sent to a > queue, and you have somehow persisted or "remembered" > any uniquer attributes of the message (like mesage ID > for example), you could use a queue browser to remove > the message before it is processed. However, I would > imaguine it unlikely that you would be able to grab > the message before it was processed if you do have > decent performance. > > In general, I am in the same mind as Chan. You should > cancel undesired asych requests before they are sent. > It is a difficult proposal to cancel any sort of > asynch request without going out of band. > > //Nicholas > > --- Chan Philip <[EMAIL PROTECTED]> > wrote: > > The Request should has been cancelled before, not > > after, it is sent. > > > > -----Urspr�ngliche Nachricht----- > > Von: Alvin Wang [mailto:[EMAIL PROTECTED]] > > Gesendet: Montag, 18. M�rz 2002 19:52 > > An: [EMAIL PROTECTED] > > Betreff: Re: [EJB-INT] Is MDB the best choice for > > asynchronous request > > handling in EJB? > > > > > > For example, I cannot cancel a request in the queue, > > and the performance > > issue... > > > > -----Original Message----- > > From: A mailing list for Enterprise JavaBeans > > development > > [mailto:[EMAIL PROTECTED]]On Behalf Of Johan > > Eltes > > Sent: Monday, March 18, 2002 12:57 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Is MDB the best choice for asynchronous > > request handling in > > EJB? > > > > > > What kind of limitations are you experiencing? > > > > /Johan > > > > -----Original Message----- > > From: A mailing list for Enterprise JavaBeans > > development > > [mailto:[EMAIL PROTECTED]]On Behalf Of Alvin > > Wang > > Sent: den 18 mars 2002 16:41 > > To: [EMAIL PROTECTED] > > Subject: Is MDB the best choice for asynchronous > > request handling in EJB? > > > > Hi! We need to do some asynchronous request handling > > work in EJB. For > > example, the user sunmits a request and quits, and > > later he comes back and > > check the status/result of his request. Currently we > > are using MDB to do > > this. However, we feel that there are some > > limitations in MDB and JMS. Is > > MDB the most natural way to handle asynchronous > > request in EJB? Can any guru > > give us some alternative design strategies? Thanks! > > > > Alvin > > > > > ==========================================================================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". > > > > > ===== > Nicholas Whitehead > Home: (973) 377 9335 > Cell: (201) 615 2716 > Work: (212) 235 5783 > [EMAIL PROTECTED] > > __________________________________________________ > Do You Yahoo!? > Yahoo! Sports - live college hoops coverage > http://sports.yahoo.com/ > > =========================================================================== > 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". > __________________________________________________ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ =========================================================================== 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".
