Nontransactional data reading
Note. This article applies to the following DBMS:
When reading data outside a transaction, take into account implementation specifics of nontransactional data reading in file and client/server modes.
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.
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: