Secure concurrency control in MLS databases with two versions of data

Abstract

In multilevel secure database systems, higher level transactions are either delayed or aborted when they read lower level data, due to lock conflicts with updating lower level transactions. Multiversion data has been suggested in the literature as a way to prevent lower reading transaction from getting delayed or aborted. In these multiversion protocols transactions that read lower level data are provided older versions of the data and thus low reading and writing operations are allowed to proceed concurrently. However almost all of these algorithms suffer from shortcomings -either they require a potentially unbounded number of versions to be maintained in the system, or they enforce a time limit in which higher level transactions have to complete. Maintaining multiple committed versions adds additional overhead to the system. Moreover, these algorithms always provide older copies of data for reading by higher level transactions which may not be acceptable for certain applications. We propose a secure concurrency control algorithm that is based on a locking strategy and that requires only two versions -one committed and one non-committed version -of data. All read operations, high or low, are performed on the previous committed version while the write operation proceeds on the uncommitted version. Thus no read operation is ever given an outdated copy. Moreover, extra overhead for version management is lesser than the other protocols because almost all transaction management systems maintains a before-image of data for recovery purposes and our scheme takes advantage of this before-image value.

Global Timestamp Serialization in Multi-Level Multi-Version DBMS

“…The concurrency control mechanisms in a multi-version DB is more flexible compared with those in a single version DB. Unlike multi-version locking mechanism [4,5] , multi-level multi-version timestamp ordering mechanism [6−8] , which is extended from the traditional multi-version timestamp ordering mechanism [9] , avoids the dilemma in a single version database by enabling transactions to read different versions of data. However, as the price of reconciliation, transactions may have to read the old version data.…”