Howard Chu wrote:
> Markus Junginger wrote:
>>> There was never a bug here. The doc is quite explicit
>>> After txn_abort the only valid call on a still-open cursor is
>>> cursor_renew, not cursor_close.
>> However you want to call it, are you open to improve this workflow?
>> API-wise, it would be so much simpler just to free a cursor after it became
>> obsolete. It's counter-intuitive to open a new txn, renew the cursor, close
>> the cursor, and abort the txn - just to close a cursor.
> API-wise, it is much simpler to just close the cursor before closing its 
> transaction, if you have no need to reuse the cursor.

To be explicit - a typical workflow, as outlined in the Getting Started guide:

Open an env
Open a txn inside the env
Open a cursor inside the txn

When finished:

Close cursor inside txn
Close txn inside env
Close env

The only reason the API allows a read cursor to exist outside of its creating 
read txn is to allow it to be reused in a later read txn. If you're not 
reusing it then you should just close it in the proper order.

   -- Howard Chu
   CTO, Symas Corp. 
   Director, Highland Sun
   Chief Architect, OpenLDAP

Reply via email to