You may observe that if there are some transactions running
alongside each other, accessing from tables in which data is
being inserted or updated, some data might be missing. You will
eventually see the complete data on later accesses.
Example to explain the problem:
------------------------------
Given :
Transactions : UOW1 and UOW2
Tables : T1 and T2
Working :
1. UOW1 INSERTs/UPDATEs data in T1
2. UOW1 INSERTs record in T2, suggesting INSERT/UPDATE to T1 is
complete
3. UOW2 SELECTs from T2 if it has a record, if yes, SELECTs *
from T1
Problem :
UOW1 performs INSERT/UPDATE on T1, then INSERT/UPDATE T2 to
indicated the new data in T1.
UOW2 queries T2 (possibly in a loop) for indication of new data
in T1, then when it sees the indication in T2 by UOW1, SELECT
from T1 for the new data, but does not see all of the changes in
T1 made by UOW1. Later on SELECT from T1 will eventually see
all the changes made by UOW1.
Explanation :
Lock attributes are used to implement currently committed
feature. It means that queries will not be blocked when seeing
uncommitted changes. However, during COMMIT processing, locks
are released serially. If another transaction executes SELECT
during the COMMIT processing, in particular when some but not
all of the locks acquired by the committing transaction have
been released, the SELECT will see some but not all of the
changes.
Note: the issue may be more pronounced in pureScale.
NOTE: In order for the fix to take effective, you will also need
to turn on the Db2 registry variable
DB2_SYNC_RELEASE_LOCK_ATTRIBUTES after applying the fix and
changes to this variable do not require the database instance to
be restarted:
db2set DB2_SYNC_RELEASE_LOCK_ATTRIBUTES=YES |
