Script Synchronization and Serialization
There may be need to avoid parallel execution of a script / multiple scripts because they may influence each other. Possible reasons:
- One execution generates a lock, 2nd (parallel) execution is blocked by this lock or cannot modify the content because it is read-only.
- Multiple logons with the same user ID are prohibited by profile parameter.
1. Use different user accounts for the same script on different robots: One account per robot, customized as variable in scope Robot.
schedule.offset.secs to set offsets.
Problem: The offset is relative to the script start. If not all robots are started at the same time the offset is arbitrary and only reliable within a single robot.
3. Use synchronization on robot level via semaphore parameters.
You want to avoid concurrent execution of script s1 and s2 on a single robot r.
semaphore.define.x = 1(type
integer) on scope robot r.
Defines a semaphore
xon this robot with 1 permit. Only one script execution assigned to use this semaphore
xcan be executed in parallel.
boolean) on scope script s1 and script s2.
Flags the script
sthat it must check out the semaphore
xfor execution. If some other script o has currently checked out x, the starting script s is blocked until script o has finished.
semaphore.define.y=5 would indicate that at most 5 scripts may be active in parallel on the robot.
A default semaphore
semaphore.define.default=1 is defined by default.
semaphore.use.default=true on scope Global would mean that on each robot there may be only one script active. But in total, multiple scripts may be active: one per robot.
You want to have two groups of scripts:
- Scripts s1 and s2 in group 1 may not be executed in parallel
- Two out of scripts s3, s4, s5 may be executed in parallel, independent from scripts in group1.
semaphore.use.default=false(do not use the default synchronization)
semaphore.define.group1=1(one at a time out of group 1)
semaphore.define.group2=2(two in parallel for group 2)
Scope script s1, script s2:
Scope script s3, s4, s5:
4. Use global synchronization across robots (new 7.1):
Global EEM semaphores reside once globally on the Solution Manager Java stack, whereas local EEM semaphores exist once independently on every robot. Global semaphores are identified via the infix
global in the configuration parameter:
semaphore.use.global.x. Do not confuse global semaphores with the configuration scope Global: global sempahores must be defined in scope Global, but you can also define a local semaphore y in the Global scope: This has the effect that the semaphore y is defined once on every robot - used for script synchronization on the robot, and users of the semaphore (scripts) can still execute concurrently on different robots.
semaphore.use.global.x=true defines a global lock with identifier
x for a script / several scripts.
Enqueue is used for locking: Use the Locking Adapter in Visual Admin to view locks or remove hanging locks.
Upon robot startup/shutdown, all locks for the robot are removed.
Locks older than 30 minutes are removed automatically when a script tries to acquire a lock.
Script will not be executed if no connection to Solution Manager is available (because lock cannot be obtained).
You can use multiple global locks for the same script, e.g.,
Use absolute offsets (new 7.1, downported to SP23P1 (SP07P1), SP08 and up):
Indicates that the
schedule.offset.secs is calculated relative to the operating system time of the robot. Time zones are ignored, .i.e., always UTC is used.
Prerequisite: system clocks on robot hosts are more-or-less in sync (use NTP!). Do sync the robots using NTP, you need to enable the robot PCs to sync their local time with a dedicated time server.
With this VBS Script you can easily sync a WIN XP client with your companies time server (some adjustement may be required for other OS). You have to change the file exentsion to .VBS in order to be able to execute it. Read the included Microsoft KB articles for more information !