When an error occurs and is caught by and Error Input Stream, why does no transaction rollback occur?

How to configure a StreamBase application for transaction rollback

A transaction applies to data objects stored in transactional memory. Transaction boundaries are largely contiguous with EventFlow concurrent regions, so when a tuple exits a concurrent region transactions initiated within that region are committed. If an error occurs within that region, transactions are rolled back and the state of transactional memory maintained by the cluster is reverted to its original state.

When a StreamBase Error Input Stream is used, by default the platform considers the error caught and "handled" as if no error occurred and when the error tuple is disposed or otherwise leaves the concurrent region the transaction is committed. 

In order to allow the StreamBase Runtime platform to roll back changes to shared concurrent transactional memory, there must be an un-handled error produced within the concurrent region and not caught.

In the example program shown here, the table update to TransactionalMemQT will be rolled back because the error caused by Div0 (which calculates: 1/0), although it is caught, is re-emitted from ErrorOutputStream. If ErrorOutputStream was not present and in the flow from ErrorInputStream, then the error caused by Div0 would be caught and not re-emitted, so no transaction rollback would occur.

If the Div0 operator is made Concurrent, then the write to TransactionalMemQT would be committed before the error from Div0 is thrown.