XML versions

Multiple versions of an XML document can coexist in an XML table. The existence of multiple versions of an XML document can lead to improved concurrency through lock avoidance. In addition, multiple versions can save real storage by avoiding a copy of the old values in the document into memory in some cases.

DB2® supports multiple versions of an XML document in an XML column if the base table space for the table that contains the XML column is a universal table space, and all other XML columns in the table support multiple versions.

With XML versions, when you insert an XML document into an XML column, DB2 assigns a version number to the XML document. If the entire XML document is updated, DB2 creates a new version of the document in the XML table. If a portion of the XML document is updated, DB2 creates a new version of the updated portion. When DB2 uses XML versions, more data set space is required than when versions are not used. However, DB2 periodically deletes versions that are no longer needed. In addition, you can run the REORG utility against the XML table space that contains the XML document to remove unneeded versions. DB2 removes versions of a document when update operations that require the versions are committed, and when there are no readers that reference the unneeded versions.

XML versions are different from table space versions or index versions. The purpose of XML versions is to optimize concurrency and memory usage. The purpose of table space and index versions is to maximize data availability.

Example of improved concurrency with XML versions: The following example demonstrates how multiple XML versions can improve concurrency when the same XML documents are modified multiple times within the same transaction.

Suppose that table T1, which is in a universal table space, is defined like this:

CREATE T1 (INT1 INT,
XML1 XML,
XML2 XML);

The table contains the following data.

An application performs SQL read operations that are represented by the following pseudocode:

EXEC SQL
 DECLARE CURSOR C1 FOR
 SELECT INT1, XML1
  FROM T1
  ORDER BY INT1
  FOR READ ONLY;

At the same time, another application performs SQL write operations that are represented by the following pseudocode:

EXEC SQL UPDATE T1
 SET XML1 = XMLPARSE(DOCUMENT '<B1>222</B1>');
EXEC SQL OPEN CURSOR C1;
EXEC SQL UPDATE T1
 SET XML1 = XMLPARSE(DOCUMENT '<C1>333</C1>');
EXEC SQL FETCH FROM C1 INTO :HVINT1, :HVXML1;

With multiple versions, the reading application does not need to hold a lock, so the updating application can do its update operations without waiting for the reading application to finish. The reading application reads the old versions of the XML values, which are consistent data.

Example of improved storage usage with XML versions: The following example demonstrates how multiple XML versions can result in the use of less real storage when an XML document is the object of a self-referencing update operation.

Suppose that table T1, which is in a universal table space, is defined like this:

CREATE T1 (INT1 INT,
XML1 XML,
XML2 XML);

The table contains the following data.

An application performs SQL operations that are represented by the following pseudocode:

EXEC SQL
 UPDATE T2
 SET XML1 = XML2,                 1 
  XML2 = XML1                     2 
 WHERE INT1 = 100;
EXEC SQL                         
 COMMIT                           3 ;

The results of those operations are:

1. When column XML1 is updated, DB2 stores the updated document as a new version in the XML table for column XML1. There are now two versions of the XML document for the second row of column XML1:

   First version:  <A1>111</A1>
   Second version: <A2>aaa</A2>

2. When column XML2 is updated, DB2 stores the updated document as a new version in the XML table for column XML2. There are now two versions of each XML document for the second row of column XML2:

   First version:  <A2>aaa</A2>
   Second version: <A1>111</A1>

3. The update operations are committed, so the old versions are no longer needed. DB2 deletes those versions from the XML tables for columns XML1 and XML2.

Without multiple XML versions, DB2 needs to copy the original versions of the updated documents into memory, so that their values are not lost. For large XML documents, storage shortages might result.