Re: Transaction Set clean does not actually clean

On Dec 18, 2007, at 6:10 PM, Mitko Haralanov wrote:

> On Fri, 14 Dec 2007 15:46:22 -0500
> Jeff Johnson <[email protected]> wrote:
>
>> 3) The Berkeley DB INIT_CDB cursor locks on rpmdb access itself.
>>
>> INIT_CDB is used for concurrent access protection with a guarantee
>> that there
>> is only a single write or multiple readers of a Berkeley DB at any
>> point in time.
>
> Hi Jeff,
>
> I believe that this is (at least, party) the situation that I am
> dealing with.
>
> What I am noticing is that the TransactionSet acquires the READ  
> lock on
> the database (in this case /var/lib/rpm/Packages) but then never
> releases it.

There's nothing within rpmlib that keeps a persistent rpmdb READ
lock that prevents using INIT_CDB afaik. If there was, then valgrind
would detect an iterator memory leak, which I'm not (and did not when
I released rpm-4.4.2 over 2 years ago) see; locks are attached to
cursors which release locks when closed. It's also rather easy to
verify that the ~15 places where cursors are used in rpmlib always
close the cursor.

Check carefully that you haven't lost track of an rpmdb
iterator within python. That would explain a persistent
READ lock.

> If what you mentioned above is true, then the INIT_CDB will not  
> allow a
> WRITE lock to be acquired by anyone unless all the READ locks have  
> been
> released.
>

Yep.

> The actual situation is even a bit worse: even when I have the
> openDB/closeDB calls in my TransactionSet wrapper, the lock
> to /var/lib/rpm/Packages is still held (despite the closeDB call) and,
> on top of everything, on subsequent reads from a Match object returned
> by the TransactionSet, I get this error message:
>
> error: cannot open Packages database in /var/lib/rpm
>

If you use openDB/closeDB calls then transitions, like
opening O_RDONLY or O_RDWR are entirely left to the application.

> I think that I am either missing something important or what I am
> trying to do just can't be done without changing the Python bindings.
>

Changed how? I don't yet hear sufficient details of what problem you
are seeing to begin to guess "can't be done without changing".

73 de Jeff