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. >
