Use the following settings to enable/disable the behavior change at file deletion time:set system fcssettings cowdblockondelete n ;
If n >=1, n is the file sharing level on which the system stops locking lxFile rows sharing the same file and sending
physical file deletion requests.
If #sharing >= n, the
new behavior is used.
If #sharing <n, the
previous behavior is used and the lxFile rows sharing the same
file are locked.
In all cases, the system still locks the
lxFile row to be explicitly deleted: at least one row
is locked.
To disable this feature:
set system fcssettings cowdblockondelete 0 ;
The default value is "10" (feature enabled) for this system setting.
Use the following settings to enable/disable the behavior change at file copy time.
The previous mode was:
set system fcssettings cowlockcopymode 1 ;
A DB lock is held on the lxFile
row related to the cloned BO/file in to prevent the deletion
of the file to be cloned.
If two users need to clone the
same BO/file, the second user will wait on the lock held by the
first user until the completion of the first user
transaction.
The mode is now:
set system fcssettings cowlockcopymode 2 ;
A new lxFile row is inserted and committed in a sub transaction for the file copy operation. Once inserted and committed, a DB lock is held on that lxFile row.
That row is flagged as "obsolete" file entry and is used to prevent the physical file deletion. That row is deleted at end of the transaction.
Consequently, two users may clone the same BO/file without having one of them waiting on the lxFile DB row lock held by the other one. Note that in the event of error, the additional inserted row may not be deleted. Since that row is flagged "obsolete", the tidy store command should be used to perform the clean-up.