[Date Prev][Date Next]
Re: (ITS#5457) bdb_add() does not always release entries
Hallvard B Furuseth wrote:
> email@example.com writes:
>>> bdb_unlocked_cache_return_entry_r(&bdb->bi_cache, p );
>> Releasing entries is somewhat irrelevant, since all locks are released when
>> the transaction commits. Note that this function is a no-op in proto-bdb.h.
>> All of those statements are just relics from the first entry cache design,
>> before we switched to using BDB locks for everything.
> OK. Does that apply to bdb_cache_return_entry_r( bdb, oe,&lock );
> bdb_cache_add( bdb, ei, op->ora_e,&nrdn, rlocker,&lock );
> failed TXN_COMMIT( ltid, 0 );
> too? bdb_cache_return_entry_r() is not a no-op.
No, that call obviously matters. But I'm not sure that this commit can ever
actually fail, or what to do about it if it does. Since all of these write ops
use a nested transaction, and there is nothing outstanding in the outer
transaction, and the inner transaction has already committed successfully, the
only thing that could cause the outer commit to fail would be something like
running out of disk for the transaction log.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/