Nontransactional data reading





Note. This article applies to the following DBMS:

  • Microsoft SQL Server versions earlier than 2005 and IBM DB2 versions earlier than 9.7;
  • Microsoft SQL Server version 2005 or later, provided that the configuration compatibility mode is earlier than Version 8.3.1.

When reading data outside a transaction, take into account implementation specifics of nontransactional data reading in file and client/server modes.

Client/server mode

In client/server mode, nontransactional reading might return incomplete data.

This is because read operations performed outside transactions use the "read uncommitted" isolation level, so that uncommitted changes made by another transactions are read. The "read uncommitted" isolation level is used because predictable performance of read operations is required and therefore pausing on locks created by other users' transactions is not not acceptable.

A notable example of this behavior is writing a great number of new documents within a transaction and then rolling back the transaction. If you open the list of documents in another 1C:Enterprise session during the transaction, you will see that documents are created in real time. Once the transaction is rolled back, all of the created documents are deleted. This is because dynamic list data is read in nontransactional mode, and therefore uncommitted changes performed within the transaction are visible to other 1C:Enterprise applications.

 

File mode

In the file mode nontransactional reading is performed differently: 1C:Enterprise 8 supports versioning during nontransactional reading. Therefore queries do not select data from uncommited changes of other transactions.

The following figure shows the differences between file and client/server mode for the example described earlier.

 

 Once the transaction is committed, the results will look like this in file and client/server mode:

 

Despite the fact that versioning is supported in file mode, executing procedures with multiple database queries still leaves a chance to get mismatched data. This can occur if another transaction changes data between the first and the second queries:

 

Conclusion
If you want to obtain complete and correct data, read data within transactions. For example, run queries within transactions. This guarantees the integrity and stability of retrieved data. If you want to read data for using it in calculations, which, in turn, will serve as a reason for changing data (for example, during document posting), always perform reading inside transactions in both file and client/server modes.
On the other hand, we recommend that you develop a reasonable approach to transaction usage: use transactions only when necessary. For example, including entire reports into transactions to ensure that you retrieve complete data is not recommended. At the same time, if you need to retrieve a consistent data set and one query is not enough for this, consider using a transaction.


Comments
0
Add comment