Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • After transaction commit and before events are sent to the gateway sender, mark last event of the transaction (a new boolean attribute “lastEventInTransaction” may be added to EntryEventImpl and GatewaySenderEventImpl)
  • In the process of creating a batch, the gateway sender must keep track of all the transactions involved in the events it is putting in the batch.
  • Once a batch is due to be sent (due to maximum configured size is reached or time), the gateway sender must check:
    • If  for every transaction to which events on the batch belong, the last event has been received, then the batch may be sent.
    • Otherwise, two options are proposed:
      • a) Keep reading events from the queue and put them in the batch until the above condition is fulfilled. Then send the batch. This option has the problem that the size of batches could grow a lot beyond the maximum size in situations of big transactions and high number of them.
      • b) Go to the queue and get selectively the events for the transactions in the batch that do not have all the events. Once these events are added to the batch, send it. This option is preferred over option a) because it should avoid the problem of batches much bigger than the maximum size configured.

...

Changes and Additions to Public Interfaces

No changes to public interfaces are proposedA new method to GatewaySenderFactory, setGroupTransactionEvents() to create gateway senders with support for this new feature must be added.

Performance Impact

The performance of gateway senders may be impacted as there will be an extra cost of keeping track of transactions in batches and also of retrieving selectively events from the queue (if this option is selected).

...

The gateway senders will behave as before if the new parameter --group-transaction-events is not used.

Versioned support for GatewaySenderEventImpl must be added due to the new field added.

Prior Art

As said above, with the current behavior of gateway senders, on the event of network splits, clients will have to deal with data inconsistencies provoked by events not delivered atomically for the time the network split is in place.

...