Using transactions to manipulate rows

In a monitor, any changes you make to Row events are local until you commit those changes. In other words, any changes you make actually modify the Row events that represent the actual rows in the table. After you commit the changes you have made to your Row events, the updated rows are available to all monitors in the correlator and to all other members of the distributed cluster if you are using a distributed store.

Note:

When you modify a Row event and you want to update the actual row with your changes, you must commit your changes. It does not matter whether or not the table is in a correlator-persistent store.

The Row event defines the following actions for committing changes:

Row.commit() — Tries to commit changes to Row events to the table. If nothing else modified the row in the table since you obtained the Row event that represents that row, the MemoryStore commits the changes and returns. The update is available to all monitors. If the row in the table has been modified, an exception is thrown, leaving the table unchanged.

Row.tryCommit() — Behaves like commit() except that it does not throw an exception upon failure. If the row in the table has been modified, this action returns false and leaves the table unchanged. If this action is successful, it returns true.

Row.tryCommitOrUpdate() — Behaves like tryCommit() except that when it returns false, it also updates your local Row event to reflect the current state of the actual row in the table. In other words, if the row in the table has been modified, this action does the following:

Leaves the actual row in the table unchanged.

Updates the local Row event that represents this row to reflect the current state of the table. Any local, uncommitted modifications are lost.

Returns false.

Row.forceCommit() — Commits the local Row event to the table even if the row in the table has been modified after you obtained the Row event.