Sdaemons

Many of the Sirius Functions interact with a facility provided with the Sirius Mods called an sdaemon. Sdaemons are threads which do work on behalf of another user. They accomplish this by automatically logging onto a requesting user's ID (under the covers), then issuing standard Model 204 commands as if the user was issuing the commands himself. This makes it possible to have Model 204 commands executed on behalf of a user while that user is running a User Language procedure.

Associated with sdaemons is the concept of family: Two threads are in the same family if one is a synchronous child sdaemon of the other via a $Comm function or a Janus SOAP Daemon object. In addition, all families with common threads are considered to be a single family. So, if thread A is a synchronous parent of thread B, which is a synchronous parent of thread C, threads A, B, and C are all considered part of the same family. Furthermore, if in this example, thread B had two other synchronous children (via Daemon objects), threads D and E, then threads A, B, C, D, and E would all be considered part of the same family.

Before Sirius Mods 6.8, threads in a family could get record locking conflicts with each other. This greatly limited what could be done on sdaemon threads. As of Sirius Mods 6.8, the one condition under which two threads in the same family can still suffer a record locking conflict is if they both try to update the same record, which would require both threads to have an exclusive pending update lock on the record being updated. This possible conflict is eliminated if the sdaemon is a Janus SOAP transactional daemon.

For more information on setting up sdaemons, see the Sirius Mods Installation Guide.