API Beans and Methods
The following Beans interact with the API:
ScriptEnvironmentBean
The createAPISessionBean() method obtains an API session Bean.
ScriptAPICommandRunnerBean
Manages and executes an Integrity Lifecycle Manager API command. The addOption() method adds an option flag to the command
ScriptAPISessionBean
Accesses and controls an Integrity Lifecycle Manager API session. The executeCmd() method executes a command.
The ScriptAPISessionBean should be used with extreme caution. It is easy to deadlock the entire server if the bean is used incorrectly. The current trigger event that is running may have resources locked. Using this bean comes back into the server and starts a new transaction, with its own set of resources and locks. That transaction shares nothing with the current event that is running; any lock currently held may block the new transaction. That new transaction waiting for the lock to release will never release because it is held by Integrity Lifecycle Manager already.
The following are scenarios in which it may be safe to use this bean:
◦ In a POST trigger. In a post trigger, all information should have been committed; all locks should have been released.
|
|
There are certain Source triggers which run the POST trigger before the entire transaction has been committed.
|
◦ In a PRE trigger, when the API is being used strictly for obtaining information. No updates are being done; no locks need to be acquired. Even in this scenario you must be extremely cautious. For Oracle, there should be no problems, as Oracle does locking completely differently from other databases. However, databases like MS/SQL Server will obtain exclusive locks on any items being created or modified in the current transaction. Any query which potentially returns the newly created or modified item will attempt to get a shared lock and deadlock.
