Issue 49: Add support for guaranteed event processing in asynchronous event handler

HI Allard,

This thread turned out to be real educational for
me. Thanks to everyone. Please read in-line:

If the machine shuts down while events are in
a queue, those messages are discarded.

The way I see it, just stating this in your product's
brochure, automatically puts your app in a class
that is unacceptable in certain industries/app-categories;
no matter how unlikely the likelihood of the happening is.

Instead of using the SimpleEventBus, simply build a
JMSEventBus or AMQPEventBus (which a colleague of mine
had done, and will be incorporated in Axon soon) ....

FANTASTIC! Exactly the kinds of things I was hoping to hear
So, Goodbye ActiveMQ! Hello Rabbit! see you soon.

This article describes how XA transactions can be avoided
http://www.javaworld.com/javaworld/jw-01-2009/
jw-01-spring-transaction ...

Nice article. Thank you. What it calls
"XA and the Last Resource Gambit" is exactly what I was
trying to describe in a previous post in this thread.

(be aware that XA transactions are expensive and not
100% safe either):

This one was an eye-opener for me; having a mainframe
mindset. But my take from the article is:
    An XA-Transaction CAN BE %100 SAFE but only with the
    high-end products.
Am I correct?
If so, it's the time (for me) to start asking around about
the price of those high-end products. More importantly, to
design systems to work with dime-a-dozen products; but make
sure the Transaction Manager is abstract enough to
accommodate one of those expensive ones. At least to make
marketing types happy by making the brochure good-looking.

Using a message broker can help in the cases where
guaranteed asynchronous processing is required.

FANTASTIC! Asynchronous is the way to go.
Hello again, Rabbit!

Thanks again for an informative and super-accurate
description; and for renovating my impressions.

/ES

Check out http://blog.jonathanoliver.com/2011/04/how-i-avoid-two-phase-commit/