Scripting actions have a lock mechanism which allows you to create critical sections within your code. You can acquire an account-wide lock of a given name, and any subsequent script actions attempting to lock on it will wait until the lock is released before proceeding. The same lock can be accessed by any action within your account.
Example
The JEF Script action example below creates a new UDO called abcd under the UDOT myudot. Admittedly this is a contrived example, but it should explain the locking semantics.
def execute() {
def udoService = flexSdkClient.getUserDefinedObjectService()
Lock lock = lockManager.getLock('mylock')
context.logInfo('Requesting lock for job ID {}', context.getExecutionId())
lock.lock()
context.logInfo('Job ID {} acquired lock', context.getExecutionId())
try {
String newUdoName = 'abcd'
def query = new UserDefinedObjectApiQuery()
query.setName(newUdoName)
UserDefinedObjectList results = udoService.getUserDefinedObjects('myudot', query)
if (results.getTotalCount() == 0) {
def udo = new NewUserDefinedObject()
query.setName(newUdoName)
udoService.createUserDefinedObject('myudot', udo)
context.logInfo('Job {} created UDO named {}', context.getExecutionId(), newUdoName)
} else {
context.logInfo('Job {} did not create UDO named {}, as it already exists', context.getExecutionId(), newUdoName)
}
} finally {
lock.unlock()
context.logInfo('Job {} released lock', context.getExecutionId())
}
}
If 2 jobs of this type are executed, the first job to run will take the lock (via lock.lock()), causing the second job to wait when it executes that line. Once the first job performs the unlock (in the finally section), the second job will continue, but skip the UDO creation as it already exists.
Comments
0 comments
Please sign in to leave a comment.