Sqlite DB lock () not getting cleared after execution

[NishchithSP]

I am running a DB update via SQL statement.execute() and clearing all bindings. Once this is done I am trying to read same table.
Ideally DB lock the database and clears the lock once statement is executed.

But db seems to be not clearing it as I am unbale to read the DB. database.isDbLockedByOtherThreads() is giving me true even taough all write/update operation is completed. This never ends and hence app is stuck and cannot do any more db operations.

My update Statement

try{
.
.
.
statement.execute();
statement.clearBindings();
.
catch(){....}
finally{
if (statement != null) statement.close();
}
.

My Get statement

.
.
.
database.rawQuery(sqlStatement, null);
.
.

My version

implementation 'net.zetetic:android-database-sqlcipher:4.5.3@aar'
implementation "androidx.sqlite:sqlite:2.3.1"

[developernotes]

Hi @NishchithSP,

Please create a small reproduction of the behavior using the SQLCipher for Android test suite. I suspect you may have another thread within your application that has acquired the lock if isDbLockedByOtherThreads() is returning true. Creating a small test within the test suite will help isolate the database related code from your overall application in determining the cause of the behavior you are seeing.

[NishchithSP]

There may be another thread obtaining lock when we execute multiple queries, But the problem is this lock is never cleared. Once lock is obtained by sql statement it is supposed to clear the lock after execution.

[developernotes]

Hello @NishchithSP,

Is this behavior something you can reproduce with a new test within the SQLCipher for Android test suite?

[NishchithSP]

This cannot be simulated inside test suite. This is happening in one of our android application. As explained theoretically it should not happen as DB should release the lock once operation is done. I am looking for information regarding any edge cases or any loopholes that's have been discovered in the past to investigate similar things.

[developernotes]

Hi @NishchithSP,

We've had no reports of the lock not being released in that type of use case. We agree that should not happen, but would need a reproducible case to investigate further.