Dirty Reads and Object Status

As mentioned, all reads are dirty reads. That is, they show the object state as of the last completed command, regardless of whether the transaction is closed or still open. Read operations include all list commands, the inexact search (that is, query) commands, and the record get commands. For example, a user opens a transaction and deletes a table under that transaction, and then runs a command to list all tables, the deleted table does not appear in the list. If the application aborts the transaction, the table is restored and a table list operation shows the restored table.

For all of the list commands, information on any marks on the object is returned along with the other statistics on the object. The user can use this to determine if an object is in a “dirty” state, and thus potentially invalid. Query commands also return a dirty flag for each record returned. An application can use this flag to disregard “dirty” records if required.

Deleted objects are not listed or returned even though the transaction that deleted them is still open. As mentioned previously, marks are retained for the deleted objects. You need to watch for the following scenario:

1.

An application opens a transaction and deletes a table.

2.

Another application lists tables and detects that the table is missing so tries to restore it and receives a conflict error.

3.

The first application commits the transaction.

When using a gateway in a clustered configuration, the mentioned scenario can occur even if explicit transactions are not used. Deleted objects are not visible, so you cannot see that they are “dirty” until you attempt to modify them.