Allow TI function Synchronized() to return immediately in case of conflict

In our application for some (complex) operations, the user asking for it has to be sure that another user is not performing the same operation on the same perimeter.

For example when user validates his forecast for BUDGET 2025 for Business Unit XX, a lot of sub-processes are executed that take time. As the figures are then validated and sent to other applications, he MUST be sure that he has exclusive access to that perimeter.

The key point is that this kind of control MUST be 'atomic', meaning that there's a guarantee that it's either totally successful or not

Today we use DataReservation for this purpose, but since this feature is deprecated in PA V12 we have to find another mechanism to implement this behavior.

We investigated using the 'Synchronized()' function to ensure perimeters exclusion, for example calling something like "Synchronized( 'BUDGET$2025$XX')", but since a second user doing the same call will be put into Wait state until the first user has finished, this is not an option.

For example if a second process tries do to a synchronization on a 'Lockname' that is already locked, this kind of information is written into the tm1server.log file (when proper debug configuration is enabled):

70072 [2348] DEBUG 2024-11-05 23:22:00.572 TM1.Lock.Exception Contention encountered attempting to acquire lock (0x0000029EE3BA7410) on object [unknown "Unknown", addr=0x0000029ED780E468, index=???-???] in IXNC mode at C:\jks\prod\workspace\Build-tm1_main-tm1server-Win64-Production\src\tm1server\prod\tm1_r7s\TM1Semaphore.cpp:69 during function 'ProcessExecuteEx'. Entering wait state 'IXC'.

Blocked by the following 1 thread:

Thread 74568 holds the lock in IXNC mode

70072 [2348] DEBUG 2024-11-05 23:22:00.572 TM1.Lock.Exception Throwing ReadOnlyConflict on object BUDGET$2025$XX

70072 [2348] INFO 2024-11-05 23:22:00.572 TM1.Process Process "MyUnlockProcess": Execution rolling back due to lock exception

70072 [2348] DEBUG 2024-11-05 23:22:00.572 TM1.Lock.Exception CommitActionLog::Rollback: Called for thread '70072' of user 'CAMID("c818420959d01246828cc3acdc8a72ef")' executing function 'ProcessExecuteEx'.

A solution would be to allow the 'Synchronized()' function to return immediately when a 'Lock' condition is encountered, instead of putting the process in a wait state.

>> The idea is to allow for another optional parameter to the Synchronized() function, to enable this behavior:

Synchronized (lockName [ , NoLockForConflicts]);

By default, NoLockForConflicts is 0

=> This is the current behavior. The process is put in IXNC when another process already has acquired the synchronization on the 'lockname'. When executed without locking, the returned value is 0.

When NoLockForConflicts is 1

=> New behavior : The function returns the Job Id of the process that has acquired the synchronization on the 'lockname'