The transaction manager includes support for transaction access to the RLV store. The transaction manager works the version manager to provide table- and row-level versioning support.
The transaction manager also works with the RLV merge to enable blocking and non-blocking merges. Blocking merges do not allow transactions to access an RLV-enabled table until the merge commits or rollback. Non-blocking merges allow transactions to exist beyond the start and end of a merge, so that these transactions still see a consistent state of the database.
After RLV-enabled tables are committed, the data resides in the RLV dbspace until a merge. (The RLV dbspace is an on-disk representation of what is in memory). The merge won't free up memory from open transactions (that is, those which have not yet ended).
When a TLV connection accesses an RLV enabled table, table-level read-write access will force a merge of the RLV store. The TLV transaction will hold a table-level write-lock, which will block RLV and other TLV connections from writing to the table for the duration of the transaction. Reads from other connections are not affected. An example of this scenario is a nightly load. The application performs a large load in the night, when the system is not being accessed. A bulk load into the IQ main portion is more efficient than loading into the RLV store and then manually triggering a merge.