If the UDR determines that its VP environment is correct and needs to remain as it is, the UDR can perform either of the following tasks.
| Lock UDR | DataBlade API Function |
|---|---|
| Lock the UDR to the current VP | mi_udr_lock( ) |
| Lock the shared-object file that contains the UDR into memory | mi_module_lock( ) |
If your UDR allocates resources that are process specific, it needs to be locked onto the VP where it started execution. When you write a UDR that needs access to global process information, you must take either of the following actions:
By executing in a single-instance VP, a UDR can be guaranteed that all invocations and instances execute in the same VP. Therefore, all UDRs can access global information of the process. (For more information, see Avoiding Modification of Global and Static Variables.) However, a single-instance VP class does have significant impact on performance and parallel scalability.
When you call mi_udr_lock( ) with an argument of MI_TRUE, you set the VP lock flag to prevent this instance of the UDR from migrating to another VP. Therefore, the UDR instance always executes on the VP where it is running. However, an MI_TRUE VP lock flag does not prevent another instance of the UDR from executing on a different VP.
If the set of UDRs in a shared-object file requires a lot of initialization or uses external resources, it can be costly to have the routine manager continually load and unload this shared-object file. To prevent the routine manager from unloading a shared-object file, use the mi_module_lock( ) function. When you call mi_module_lock( ) with an argument of MI_TRUE, you set the module-lock flag, which locks the shared-object file in memory. Therefore, the routine manager does not allow the shared-object file to be unloaded for any reason.
This feature enables a DataBlade (or group of related UDRs) to prevent its shared-object file from being unloaded in any of the following cases:
Home | [ Top of Page | Previous Page | Next Page | Contents | Index ]