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.
