Abstract: What are some of the performance, transactional and crash recovery issues to consider for transactional and non-transactional DataStores?
When transaction support is enabled I have found the JDBC driver and DataExpress to be of similar performance. DataExpress is slightly faster for simple insert/update/delete operations
When transaction support is disabled (DataStore.TxManager property is null or DataStore.TxManager.Enabled property is false), only DataExpress can be used (we may support non transactional JDBC in the future). This is usually at least twice as fast as using a Transactional DataStore. Note that to disable a DataStore that is already transactional, you must either 1) Use DataStoreExplorer or 2) Instantiate a TxManager component, set the TxManager.Enabled property to false and then set this TxManager to your DataStore.TxManager property. You can't just set the DataStore.TxManager property to null to disable transaction support.
For changes to be persistent there are two cases to consider:
1) Transactional DataStore. For JDBC, java.sql.Connection.commit() must be called or the connection needs to be in autoCommit mode. For DataExpress, the DataStoreConnection.commit() method must be called. Note that closing a connection will also cause an outstanding transaction to be committed.
2) Non-transactional DataStore. Again, only DataExpress components can access these at this time. There is a DataStore.SaveMode property that controls the saving of dirty cache blocks. There is also a Daemon thread (also used for transactional DataStores) that saves dirty pages every 100 milliseconds by default. There is a DataStore.SaveInterval property that can be used to adjust this frequency. DataStore.save() and DataStore.close() force all dirty cache pages to disk. So by default we get dirty pages to disk pretty quickly.
Whether or not a DataStore is transactional, we always know if the DataStore was shutdown properly. There is a Response event that can be wired via the DataStore.addResponseListener, that will tell you lots of interesting things including the fact that a DataStore was not shutdown properly (i.e. system or application crash). With a transactional DataStore, crash recovery will proceed to repair the DataStore and rollback uncommitted transactions. With a non-transactional DataStore, you can run StreamVerifier.verify() on the DataStore. If there are errors, you could use DataStoreConnection.copyStreams() to repair the DataStore.
Use transactional DataStore for for JDBC SQL access, crash recovery, and transactional semantics (commit/rollback).
Use non transactional DataStore for higher performance with a small chance of data loss (no crash recovery). You may want to primarily run with transaction support enabled, but disable transaction support to quickly perform a time consuming batch operation. The drawback to such an optimization is that a failure during the long running batch operation could leave your DataStore file in a damaged state.