Sdaemons: Difference between revisions
mNo edit summary |
mNo edit summary |
||
Line 28: | Line 28: | ||
For more information on setting up sdaemons, | For more information on setting up sdaemons, | ||
see the [http:// | see the [http://m204wiki.rocketsoftware.com/images/c/c9/SiriNew.pdf Sirius Mods Installation Guide]. | ||
[[Category:Overviews]] | [[Category:Overviews]] |
Revision as of 21:53, 8 September 2014
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.
One condition exists under which two threads in the same family can still suffer a record locking conflict: 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.