Re: [sqlite] interesting deadlock.

2012-10-12 Thread Jonathan Engle
Thanks for your help Dan, works like a charm (the work-around, haven't tried the new code yet). One question, usage-related. So the reason I'm all of this with the hot backup is that when certain tables are changed, we want to create a snapshot of the database. We do this by marking an

Re: [sqlite] interesting deadlock.

2012-10-05 Thread Dan Kennedy
On 10/05/2012 04:29 AM, Jonathan Engle wrote: Ok, so here's a question (trying an experiment to see if this will work, but throwing it out here as well). What if the source db handle for the backup is opened to use private cache? Will this have any effect at all or is it the cache mode of db2

Re: [sqlite] interesting deadlock.

2012-10-04 Thread Jonathan Engle
Ok, so here's a question (trying an experiment to see if this will work, but throwing it out here as well). What if the source db handle for the backup is opened to use private cache? Will this have any effect at all or is it the cache mode of db2 (using your example below)? On Sep 28,

Re: [sqlite] interesting deadlock.

2012-09-28 Thread Dan Kennedy
On 09/28/2012 03:32 AM, Jonathan Engle wrote: I've been picking away at this for the last few days and have it narrowed down fairly well. It looks like if I turn off shared cache, it works fine (same application code). If I run with SQL_DEBUG enabled, the first issue I run into in an assertion

Re: [sqlite] interesting deadlock.

2012-09-27 Thread Jonathan Engle
I've been picking away at this for the last few days and have it narrowed down fairly well. It looks like if I turn off shared cache, it works fine (same application code). If I run with SQL_DEBUG enabled, the first issue I run into in an assertion in sqlite3BtreeEnter: assert(

Re: [sqlite] interesting deadlock.

2012-08-25 Thread Jonathan Engle
No, the deadlock is deeper than that, it's stuck trying to lock mutexes. My current theory is that the thread trying to update the page in the backup destination database is what's causing trouble. I also forgot to mention, each thread is using a different connection object and that it's

Re: [sqlite] interesting deadlock.

2012-08-25 Thread Patrik Nilsson
Do you test for the backup errors, i.e. SQLITE_BUSY and SQLITE_LOCKED? Do you test for step errors, i.e. SQLITE_BUSY? If you get the busy error, you can wait a while and try again or start over. /Patrik On 08/24/2012 05:46 PM, Jonathan Engle wrote: > Ran into this recently, it's happened on

[sqlite] interesting deadlock.

2012-08-24 Thread Jonathan Engle
Ran into this recently, it's happened on one machine running a beta test of our software. This is a multi-threaded application, and I've run into a sequence of steps that deadlocks hard that as far as I can tell from the documentation shouldn't. This is using SQLite 3.7.13 with SEE. The