An IRS-DBMS architecture in which an Information Retrieval System (IRS) piggy-backs on a Data Base Management Systems (DBMS) is described. In this context, the issues of concurrency control and recovery are addressed. Given that IRS objects and operations are at a higher level relative to DBMS objects and operations, it is necessary to map an IRS transaction to one or several DBMS transactions. Two possible approaches, one-to-one transaction mapping and nested transactions, are examined. The one-to-one mapping is simple and the functions of concurrency control and recovery can be completely handled by the DBMS layer. However, this solution leads to a low degree of parallelism due to the generation of “pseudo-conflicts.” In contrast, if transactions are nested whereby each IRS transaction is mapped to a sequence of DBMS transactions, then the parallelism would be improved, but only the atomicity of IRS operations (and not IRS transactions) would be preserved. Thus, in this situation, multi-user-control and recovery facilities must also be provided at the IRS-layer. It is mentioned that predicate-oriented locking approach could be employed for the IRS-level serializability testing. The kind of nested transactions adopted is comparable to the notion of “open” nested transactions in [1].