Save the memory address
In addition to ensuring that the allocated memory has an appropriate memory duration, you must ensure that the UDR can obtain the address of this memory when it needs to access the information within the memory.
For example, if you allocate PER_COMMAND memory within a UDR but
only store its address in a local variable, this address is deallocated
when the UDR completes.
Important: The deallocation of
the memory address but not the associated memory is one of the most
common causes of memory leaks. Make sure that the duration of the
memory address is compatible with that of its memory.
The following table summarizes common ways to save a memory address.
| Memory duration | Where to store memory address | Scope of address |
|---|---|---|
| PER_ROUTINE | Does not need to be handled because the memory and its address are only valid within a single routine invocation. | Current® invocation of UDR |
| PER_COMMAND | Store the memory address in the user state of the MI_FPARAM structure. You
can take special steps (such as named memory) to store the memory
address so that it can be accessed by other UDRs:
|
All invocations of the UDR within the current SQL
command All UDRs that know the name of the named-memory block All UDRs that have access to the session-duration connection descriptor |
| PER_STMT_EXEC | If the SQL statement does not contain any subqueries,
you can store the memory address in the user state of the MI_FPARAM structure.
If the SQL statement contains subqueries, you must take special steps (such as named memory) to store the memory address so that it can be accessed by other instances of the same UDR or by other UDRs. |
All invocations of the UDR within the current SQL statement |