Enabling this option causes the CLOSE
cursor-name database
request to be queued, and then sent to the server with the next
database request. This eliminates a network request each time a
cursor is closed.
Anywhere
YES, NO
NO
When this parameter is enabled, cursors are not actually closed
until the next database request. Any isolation level 1 cursor stability
locks still apply to the cursor while the CLOSE
cursor-name database
request is queued.
Enabling this option can improve performance if:
Your network exhibits poor latency
Your application sends many cursor open and close requests
Note that in rare circumstances, canceling the next request
after the CLOSE
cursor-name database
request can leave the cursor in a state where it appears to be closed
on the client side, but is not actually closed on the server side. Subsequent
attempts to open another cursor with the same name will fail. Using
LazyClose is not recommended if your application cancels requests frequently.