Skip to Content

ADS Locking Updates while Creating AOF

There is no direct method provided by Advantage for doing this.  The locks that are acquired are all automatically obtained, and there is no way to provide a timeout value for them.  Also, I am not aware of any simple method for a client to determine if an AOF is being built on a certain table.  It would be possible to use the management API (either sp_mgGetWorkerThreadActivity or AdsMgGetWorkerThreadActivity) to find out if an AOF is being built.  The op code returned could be used to determine if an AOF build was active.  But then it would require some extra calls to determine which tables were opened by the user doing the AOF build (I don't think it would be possible to definitively nail down which table the build was on via those APIs).  Even if an application made the call to see if *any* AOFs were being built, there is no guarantee that one would not be in process in the next millisecond after that call (and before an update operation).

It might be possible for an application to set up some kind of shared protocol via some field in a table.  If the value has some known value, it means someone is building the AOF.  For example, "update serializertable set numaofbuilds = numaofbuilds + 1" before the AOF build and then decrement it after the build operation.  Again, though, that has the problem of not easily guaranteeing that a build doesn't start right after a client checked it.

If the AOF builds that are resulting in this problem are "rare" events, maybe use AdsLockTable prior to setting the AOF.  That would prevent the ability for updates to occur (they would fail immediately rather than wait for the duration of the index scan caused by the AOF build).

No comments