well i don't like it because for asynchronouism you now have some tools in JavaEE. then i agree the retry mecanism can be interesting but 1) did you already look what does the container (AMQ here) when you send/receive a message? i wouldn't try to get any perf with such a lot of job 2) AMQ blocks easily and it is as easy to get twice the same message or lost it so i wouldn't bet on it
don't take it bad, AMQ is fine in general but got so much issues that i wouldnt use it when i stay in the same JVM @Asynchronous should be interesting that's said when a server is really used async is useless (work has to be done :p) Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2012/12/17 Howard W. Smith, Jr. <smithh032...@gmail.com>: > Good points Anthony and thanks for sharing all that. Stephen, right now, I > assume the same as what you stated. My experience with entirely @stateless > solution, IMHO, got me nowhere because @stateless seems to be application > scope and the database got locked application scope/wide, so that is why I > reverted to user session being responsible for the update. JMS seems a bit > @stateless in its nature to me. I honestly believe that entirely @stateless > can perform narrower scope transactions. Maybe one day I can achieve such a > thing. :-) > On Dec 16, 2012 7:07 PM, "Anthony Fryer" <apfr...@hotmail.com> wrote: > >> Romain, you're opinion means alot so i'm wondering why you are against JMS >> in >> this case. This kind of pattern happens alot in my experience. In this >> case a timer job executes that finds a list of jobs to execute, in this >> case >> read a list of emails and for each email insert a row into a database. >> >> In my experience, the timer job that executes wants to finish as quickly as >> possible so you don't get overlapping timer executions and also to minimize >> resource utilization. Putting a jms message on a queue is generally alot >> quicker than performing an actual database insert. In addition JMS gives >> you guaranteed message delivery, so you know that the message is going to >> get processed and not get lost. It is part of the JMS spec that i believe >> is very applicable in this case. >> >> As for the transactional semantics that apply to the Message Driven Bean >> that performs the actual work of inserting the record into the database, >> again i think it works well in this case. If the MDB is executing within a >> container managed transaction, then only if the database insert succeeds >> and >> the transaction commits will the message be taken off the queue. This >> means >> if the database insert fails, you haven't lost the message and can either >> retry or configure the JMS to place the message on an error queue that can >> be processed in a different way. >> >> How would you handle a database insert failure in the current solution? >> >> Also I don't think it matters if the MDB that performs the message >> processing is local or not. Its irrelevant really. I wouldn't be using >> the >> JMS just for asynchronous calls. I'd be using it for the guarenteed >> message >> delivery and processing, performance AND asynchronous processing. >> >> >> >> >> >> >> -- >> View this message in context: >> http://openejb.979440.n4.nabble.com/Re-Why-are-Tomcat-s-threads-more-costly-than-background-threads-tp4659429p4659710.html >> Sent from the OpenEJB User mailing list archive at Nabble.com. >>
