I disagree. Reading data starts a transaction implicitly, meaning that the session is entitled to read consistency until it explicitly ends the transaction. Some DBMSs ensure read consistency using pessimistic locking. If a session that no longer requires read consistency fails to commit then the the lock is held and blocks writers. (DBMSs that use MVCC or optimistic locking won't notice that the transaction is being needlessly prolonged.) On the basis that the benchmark attempts to be DBMS agnostic it must commit as soon as read consistency is no longer required regardless of whether there has been an update.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
These transactions only read data and never update data. Commit only needs to be called when updating data.
I disagree. Reading data starts a transaction implicitly, meaning that the session is entitled to read consistency until it explicitly ends the transaction. Some DBMSs ensure read consistency using pessimistic locking. If a session that no longer requires read consistency fails to commit then the the lock is held and blocks writers. (DBMSs that use MVCC or optimistic locking won't notice that the transaction is being needlessly prolonged.) On the basis that the benchmark attempts to be DBMS agnostic it must commit as soon as read consistency is no longer required regardless of whether there has been an update.