Transaction Event Loss Due to JMS message failures

Transaction events generally reach the client via the named graph update JMS system. Each named graph update message for a transaction contains all of the information about that transaction. Thus, even if only a single named graph update is received for a transaction involving 100 graphs, replication can be used to retrieve all the missing data, and the information in that single received update, can be used to fire the transaction event once replication is complete.

However, if no messages are received for transaction, however unlikely, a transaction could be missed all-together and the named graph update system won't even know to replicate the missed graphs. The missed data will likely be solved next time an update is received for one of the graphs because the graph revisions won't match, and a replication will be forced. However, the transaction event associated with the revision (s) in between will never reach the client.

We could take great lengths to solve this problem. We could store the transactionUri responsible for each revision change in each named graph, along with the context and graph information. However, this is a lot of extra storage to make up for a rare error case. We could limit how long we store the transactions, but how long? There would still be a chance of a client losing the event.

So instead, we encourage our application developers and users to not rely completely on receiving all transaction events, and gracefully absorb a missed transaction event now and again. The extend of this sensitivity will be dependent on how many events we see lost due to JMS failures. In the end, we may have to store the transactions if it becomes too much of a problem, but we defer for now.