I think I have discovered the problem. SQLiteManager::init( const string&
dbFileName, const bool deleteDbFileFlag = true ) was deleting and
recreating the database file for each new connection. That was probably
corrupting SQLite state and a SQLITE_IOERR_DELETE_NOENT was correctly being
returned at transaction ending, since the original file to write was
replaced by another one. Some multithreaded tests are passing already. I
will finish the tests to put the final verdict here.
2016-02-03 12:56 GMT-02:00 Vin?cius da Silva <dsilva.vinicius at gmail.com>:
> With a single thread and two interleaved transactions, the tests hangs in
> what seems a deadlock.
>
> 2016-02-03 12:21 GMT-02:00 Clemens Ladisch <clemens at ladisch.de>:
>
>> Vin?cius da Silva wrote:
>> > Using BEGIN EXCLUSIVE TRANSACTION in place of BEGIN TRANSACTION does not
>> > change the result
>>
>> I meant, try executing them so that they are guaranteed to conflict, like
>> this:
>>
>> db1.init("same_file");
>> db2.init("same_file");
>> db1.beginTransactionExclusive();
>> db2.beginTransactionExclusive();
>>
>>
>> Regards,
>> Clemens
>> _______________________________________________
>> sqlite-users mailing list
>> sqlite-users at mailinglists.sqlite.org
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>
>
>
>
> --
> Best Regards,
>
> Vin?cius da Silva <http://www.lcg.ufrj.br/Members/viniciusdasilva>,
> Ph. D. Student.
> PESC <http://www.cos.ufrj.br> - UFRJ <http://www.ufrj.br>
>
--
Best Regards,
Vin?cius da Silva <http://www.lcg.ufrj.br/Members/viniciusdasilva>,
Ph. D. Student.
PESC <http://www.cos.ufrj.br> - UFRJ <http://www.ufrj.br>
