During the scan process, multiple threads access the user’s view, potentially accessing resources on which the user has accounts. After the view is accessed, multiple audit policies and rules are evaluated, which may result in the creation of compliance violations.
To prevent two threads from updating the same user view at the same time, the process establishes an in-memory lock on the user name. If this lock cannot be established in (by default) 5 seconds, then an error is written to the scan task and the user is skipped, thus providing protection for concurrent scans that are processing the same set of users.
You can edit the values of several “tunable parameters” that are provided as task arguments to the scan task:
clearUserLocks (Boolean). If true, then all current user locks are freed before the scan starts.
userLock (integer). Time (in milliseconds) to wait when trying to lock a user. The default value is 5 seconds. A negative value disables locking for that scan.
scanDelay (integer). Time (in milliseconds) to sleep between dispatching scan threads. The default value is 0 (no delay). If you provide a value for this argument, then the scan is slower, but the system is more responsive to other operations.
maxThreads (integer). Number of concurrent threads used to process a scan. The default value is 5. If resources are very slow to respond, increasing this number may increase scan throughput.
To change the values of these parameters, edit the corresponding Task Definition form. For more information, see Chapter 2, Waveset Forms, in Oracle Waveset 8.1.1 Deployment Reference.