-
Title
Do SharePlex treat the target row as out of sync and discard subsequent DML for that row if the row is synchronized outside of SharePlex and SP_OPO_ERR_ROWID is set to 1 for caching out of sync rows? -
Description
The parameter SP_OPO_ERR_ROWID if set to 1 caches out of sync rows in memory for the purpose of efficiency of applying transactions. This article delves on the working of parameter as it relates to a situation where the out of sync row is synchronized outside of SharePlex.
-
Cause
When SP_OPO_ERR_ROWID is set to a default of 1, Post caches rowid for out of sync rows in the current transaction only. -
Resolution
When the SP_OPO_ERR_ROWID is set to a default of 1, SharePlex does indeed cache out of sync rows so as to not run subsequent SQL statements on that row if prior statements failed. However, this is only done for DML within the same transaction. So, for example, if there are 100 UPDATEs to the same row in one transactions, and if the first UPDATE fails with the parameter SP_OPO_ERR_ROWID set at 1, the subsequent 99 UPDATEs will be ignored. But with the next transaction, Post will again attempt to apply the DML on that out of sync row. The reason being, the cached out of sync rows are stored in memory for the duration of transaction only for the purpose of efficiency of posting. The rowids are not stored permanently, or for that matter they are not stored for a long time. If you do attempt to fix the out of sync manually, it would, in all likelihood be done after the Post applies that transaction which encountered the out of sync. So even if you subsequently fixed that out of sync row, any transaction involving that rowid will be applied normally by Post and that rowid will not be ignored for any future transactions. That rowid is only ignored for the duration of the transaction that encountered out of sync on that rowid and subsequent transactions will always attempt to posts to that rowid. Hence it can be said that the manual sync of the row will not add to the slowness in posting as such manual DML will only occur outside of the earlier transaction that cached the rowid as out of sync but Post subsequently cleaned the cache once the previous transaction completed.