SQLite Forum

Unexepected commit result with two threads application

I met an unexpected Sqlite behavior in my note-taking application on Windows. But I may have wrong assumptions about how locking is working so maybe a fix in the code is needed.

The application basically uses the same db in two threads. But each one opens a separate db connection (the same db physical path). 
- Thread 1 is about all general information retrieval and change (UI thread).
- Thread 2 is for quick search in the search box in order to show a popup list of the phrases met a search criteria while the user is typing. 

The problem is when the application want to commit in the main thread (after several Update statements), but quick type search is still searching, the overall consequence looks like a rollback effect: commit returns SQLITE_OK, no new changes in the data, the rollback file is gone and the date of the main db file is the one that was before this change was tried.  

I checked this with 3.32.01 version, Windows 7, 32 bit app 

Do I expect too much about auto-locking handling and probably still need some inter-thread locking mechanism despite the fact that the connections are different?