Wow, this was actually quite obvious, I don't know how I missed that.
Thanks a lot,
Mikolaj
On 03/07/12 14:41, Pavel Ivanov wrote:
First your second process gets a SHARED lock on the database to read
it, then your first process gets RESERVED lock on the database to
indicate that it will change
On Wed, Mar 07, 2012 at 12:40:08PM -0500, Pavel Ivanov scratched on the wall:
> >> Another option is to start IMMEDIATE transaction in the second process
> >> to avoid this course of action altogether.
> >
> > ?Yes. ?That won't fix the issue (you'll still get contention issues
> > ?that will requir
>> Another option is to start IMMEDIATE transaction in the second process
>> to avoid this course of action altogether.
>
> Yes. That won't fix the issue (you'll still get contention issues
> that will require restarting the transaction) but they'll show up
> at the beginning of the transaction
On Wed, Mar 07, 2012 at 08:41:17AM -0500, Pavel Ivanov scratched on the wall:
> First your second process gets a SHARED lock on the database to read
> it, then your first process gets RESERVED lock on the database to
> indicate that it will change it. Then your second process tries to
> promote its
On 7 Mar 2012, at 1:55pm, Pavel Ivanov wrote:
> On Wed, Mar 7, 2012 at 8:49 AM, Simon Slavin wrote:
>> On 7 Mar 2012, at 1:41pm, Pavel Ivanov wrote:
>>
>>> First your second process gets a SHARED lock on the database to read
>>> it, then your first process gets RESERVED lock on the database t
On Wed, Mar 7, 2012 at 8:49 AM, Simon Slavin wrote:
> On 7 Mar 2012, at 1:41pm, Pavel Ivanov wrote:
>
>> First your second process gets a SHARED lock on the database to read
>> it, then your first process gets RESERVED lock on the database to
>> indicate that it will change it. Then your second p
On 7 Mar 2012, at 1:41pm, Pavel Ivanov wrote:
> First your second process gets a SHARED lock on the database to read
> it, then your first process gets RESERVED lock on the database to
> indicate that it will change it. Then your second process tries to
> promote its SHARED lock to RESERVED one,
First your second process gets a SHARED lock on the database to read
it, then your first process gets RESERVED lock on the database to
indicate that it will change it. Then your second process tries to
promote its SHARED lock to RESERVED one, sees that RESERVED lock has
been already taken and can't
On 7 Mar 2012, at 9:00am, Mikołaj Radwan
wrote:
> After a couple iterations both processes start getting the "database
> locked" error and never work again unless one of them is killed.
My guess is that one or other processes are not closing the connection properly
on the run previous to the
Hi all,
For a couple days now I've been trying to figure out this problem and
can't seem to manage.
I have two processes, both of which connect to the same SQLite database
and do the following:
process 1:
# opens database
PRAGMA foreign_keys = ON;
PRAGMA journal_mode = PERSIST;
INSERT INTO som
10 matches
Mail list logo
