Re: [sqlite] In what case will the online backup api hang for acquiring the Btree lock of the destination on-disk file?

On 22 Jul 2016, at 3:10am, Quan Yong Zhai wrote: > If remove use of shared cache from file specifications, they will be two > separated memory databases I am sorry. I didn't think of that. I agree that you need shared cache to make your program work. Simon.

Re: [sqlite] In what case will the online backup api hang for acquiring the Btree lock of the destination on-disk file?

If remove use of shared cache from file specifications, they will be two separated memory databases 发件人: Simon Slavin 发送时间: ‎2016/‎7/‎22 9:32 收件人: SQLite mailing list 主题: Re: [sqlite] In

Re: [sqlite] In what case will the online backup api hang for acquiring the Btree lock of the destination on-disk file?

On 22 Jul 2016, at 2:12am, Yihong Zhan wrote: > Thanks Quan Yhong and Stephen. Today I did more experiment and finally > narrowed down the cause (but not the root cause) of the problem. Please remove all use of shared cache from your file specifications and try again.

Re: [sqlite] In what case will the online backup api hang for acquiring the Btree lock of the destination on-disk file?

Thanks Quan Yhong and Stephen. Today I did more experiment and finally narrowed down the cause (but not the root cause) of the problem. Under the following situation the in-memory source database and the NFS disk destination database will meet deadlock across 2 threads: * Thread 1 (T1)

Re: [sqlite] In what case will the online backup api hang for acquiring the Btree lock of the destination on-disk file?

Thanks for everybody’s help. Today I did more experiment and finally narrowed down the cause (but not the root cause) of the problem. Under the following situation the in-memory source database and the NFS disk destination database will meet deadlock across 2 threads: * Thread 1 (T1)

Re: [sqlite] In what case will the online backup api hang for acquiring the Btree lock of the destination on-disk file?

On 20 Jul 2016, at 9:03am, Yihong Zhan wrote: > * std::string m_tmpFileName = > "file:/NFS/some_dir/database?mode=memory&=shared”; > * int rv = sqlite3_open_v2(m_tmpFileName.c_str(), _sqlObj, > SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE |

Re: [sqlite] In what case will the online backup api hang for acquiring the Btree lock of the destination on-disk file?

Thanks Quan Yhong. Today I did more experiment and finally narrowed down the cause (but not the root cause) of the problem. Under the following situation the in-memory source database and the NFS disk destination database will meet deadlock across 2 threads: * Thread 1 (T1) creates an

Re: [sqlite] In what case will the online backup api hang for acquiring the Btree lock of the destination on-disk file?

Quan; If a single process/thread is dumping to the NFS, it shouldn't matter, especially since the backup routine is one-way, and there are no 'transactions' happening which would cause locking failures. This is more relevant when you have active transactions fighting with the live database where

Re: [sqlite] In what case will the online backup api hang for acquiring the Btree lock of the destination on-disk file?

https://www.sqlite.org/faq.html#q5 “But use caution: this locking mechanism might not work correctly if the database file is kept on an NFS filesystem. This is because fcntl() file locking is broken on many NFS implementations. You should avoid putting SQLite database files on NFS if multiple

[sqlite] In what case will the online backup api hang for acquiring the Btree lock of the destination on-disk file?

Hi sqlite experts, I am currently incorporating the sqlite online backup API (version 3.8.0.2) into our product. I meet a tricky problem, where the sqlite3_backup_step hangs at acquiring the BTree’s lock of the destination file. Specifically, I am backing up in-memory database to NFS disk