Transactional Executor with Retry?

Please a bit of advice on the following:

I am using a ThreadPoolTaskExecutor to execute slow-external tasks like sending emails.

I need to improve this: 1) When the a task is passed to the exeuctor, it has to wait executing it till at least the transaction of the passing operation has finished. Example: i makes no sense to email something when the order process fails and generates an exception which occurs on commitment

2) When the task fails, some retry mechanism is used to try the task again. Example: when sending the email fails, it will be retried after 5,10 minutes and th开发者_运维百科en throws an exception.

How to deal with these issues? of should I just integrate some queue that offers this functionality?..

Ed

---

I would say : yes use a queue in a messaging infrastructure.

Personally I would use Camel for this because I am completely smitten by Camel and would use it if I would reprogram my toaster to toast the slices golden brown at breakfast.

Since you are going to mail, it will be message based anyway, so using a message based system will already reduce the impedance mismatch.

Now things as transactions, retries and parking the message on a dead letter queue comes as standard with these things. This is nice, because you can then script your way out of trouble when a email server disaster hits, by resubmitting the messages from the dead letter queue.

Integrating an ActiveMQ or a Camel is just adding a couple of dependencies and 5-10 lines in your spring configuration.

Once it is in there it is beautiful to organize background processing, notify remote systems, automate email responses, notify sysadmins of impending doom, ... You send a message, continue what you're doing, respond to the customer, while in the background the wheels are turning.

Ok, sorry : I got carried away and got way too lyrical.