Troubleshooting considerations for annotated XML schema decomposition

General considerations

• Check that the XSR object that corresponds to your XML schema appears as enabled in the DECOMPOSITION column of the SYSCAT.XSROBJECTS catalog view. If the XSR object is not enabled, consider taking the corrective actions described in the disablement documentation.
• Ensure that the limits and restrictions for XML decomposition are not violated.
• Ensure that the XML document is valid according to its XML schema. Validation is not a requirement for decomposition, however, if you expect certain behavior, such as character entity expansion, then perform decomposition with validation.

XML schema issues

• Ensure that XML schema does not contain errors such as non-deterministic content models, as these types of errors can cause decomposition to fail when validation is performed, or undefined decomposition results if validation is not performed.
• Ensure that the non-global annotations have been declared only on element or attribute declarations and not on complex types, element/attribute references, model groups or any other xml schema construct. Also check that the annotations are declared in their supported format: as attributes, elements, or global annotations. (Refer to the documentation on each annotation for details of how to specify an annotation.)
• Ensure that complex types derived by extension or restriction are annotated properly.

Specific errors

Locking and concurrency

If you are experiencing lock escalation or deadlock when decomposing documents, adjust concurrency control through your application. If an application makes multiple concurrent invocations of any of the xdbDecompXML stored procedures, where many of the same tables are involved in the multiple decomposition operations, then the application needs to manage the concurrent access to these tables to prevent lock escalation and deadlock.

One way to adjust concurrency control is to explicitly lock all tables involved in the decomposition before invoking the xdbDecompXML stored procedure. Then execute the COMMIT or ROLLBACK statements as appropriate after the stored procedure has returned. Because the decomposition of large documents can result in a large number of rows being inserted, and because each row is locked by default during an insert operation, an application that is inserting many rows can hold many row locks, leading to lock escalation. By obtaining table locks instead, you can avoid the overhead of obtaining row locks and of lock escalation.

If the reduced concurrency associated with obtaining table locks is not appropriate for your application, you can increase either or both of the maxlocks and locklist database configuration parameters, which decreases the likelihood of lock escalation.

Set the locktimeout database configuration parameter to prevent an application from waiting indefinitely to obtain a lock.

Mapping verification in catalog view