On interactions between transaction and events

As a follow up to the transactions vs. events posting,  I would like to discuss some interactions between event processing and events.  ACID  (Atomicity, Consistency, Isolation, Durability) are the properties of classic transaction systems that guarantee serializibility. 


 Some people think that event processing and transactions live on two separate universes,  as event driven architecture advocates asynchronous mode and decoupling.   Note that there are transactional asynchronous systems (e.g. messaging with guaranteed delivery).    


One of my past Master students, Boris Shulman, has investigated the issues of interactions between transactions and events. There was no paper published from his thesis,  he has done the thesis while working for IBM, but then went to work in a start-up and did not have time to complete a paper, and the topic was not on top of my priorities either,  but recently I am thinking about it more. 


In the thesis he pointed out several different motivations to look at the combinations of events and transactions:

1. A monitoring system that monitors a transaction system,  events are emitted from the running transaction systems,  in a way, emitting such events before transaction commit, violates the "isolation" requirement of the ACID.   However,  at some cases there are timing constraints, since the monitored event need to be processed without delay.   This gets complicated when the transaction aborts, and all transactions operations rollback.   In this case the monitored event conceptually never happened. 
2. Event processing is done as part of an actual transaction,   the producer and consumer are part of a transaction, and the event processing is doing some processing that happen to fall into the functionality it support, but it is part of transaction.   Note that this does not view event processing as a stand-alone functionality, but as a functionality that can be embedded in other systems that can be transactional.  In the past when we did the Amit nodes inside IBM Websphere Message Broker, it worked exactly in that mode,  event processing as a specific node within a transactional message flow.
3. The event processing network (or a certain path in it) may have a requirement to behave as a single unit of work.   This is true when an EPA reads/write data, but also the raw events and derived events may issue transactional behavior.     

There might be other cases,  but these cases indicate some cases for interactions between transactions and events.   The transactions that relate to events, may not be  pure ACID transactions, I'll discuss other model of transactions that might be appropriate - later.