On 2/10/2012 2:57 PM, Marc L. Allen wrote:
MSSQL in its default serialization mode does not guarantee repeatable
reads within a transaction. But, it provides locking hints to help
enforce it when required. I'm guessing that sqlite does guarantee
repeatable reads?
SQLite implements only one tr
> -Original Message-
> From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-
> boun...@sqlite.org] On Behalf Of Igor Tandetnik
> Sent: Friday, February 10, 2012 2:36 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Database locked in multi process scenario
On 2/10/2012 12:29 PM, Sreekumar TP wrote:
Can this situation be handled in sqlite - by upgrading the lock to a
writer lock ? Since both applications use the same WAL file for read and
writes, it shouldnt be a problem , because all changes will be in linear
sequence ?
Consider again:
[1] BEG
On 10 Feb 2012, at 5:55pm, Kit wrote:
> 2012/2/10 Simon Slavin :
>> On 10 Feb 2012, at 5:32pm, Kit wrote:
>>> A situation in which I read from the database first and then changes
>>> the data tells me that they are wrong questions. It is such a problem
>>> to insert SELECT into UPDATE or INSERT?
2012/2/10 Simon Slavin :
> On 10 Feb 2012, at 5:32pm, Kit wrote:
>> A situation in which I read from the database first and then changes
>> the data tells me that they are wrong questions. It is such a problem
>> to insert SELECT into UPDATE or INSERT?
>
> Why do you need to do a SELECT at all ? C
On 10 Feb 2012, at 5:32pm, Kit wrote:
> 2012/2/10 Sreekumar TP :
>> Though the example of $ is very intuitive, I am not suggesting that we
>> drop one of the transaction and block the database forever (as it is
>> happening now). Instead, it could be serialized such that two $100
>> transactions
On Fri, Feb 10, 2012 at 11:45 AM, Sreekumar TP wrote:
> There is no recovery from this situation-
>
The recovery from your situation is to reset or finalize the initial query
that is holding the transaction option.
>
> If you try to rollback, you get the following error -"cannot rollback
> save
On 10 Feb 2012, at 5:29pm, Sreekumar TP wrote:
> Can this situation be handled in sqlite - by upgrading the lock to a
> writer lock ? Since both applications use the same WAL file for read and
> writes, it shouldnt be a problem , because all changes will be in linear
> sequence ?
SQLite handle
2012/2/10 Sreekumar TP :
> Though the example of $ is very intuitive, I am not suggesting that we
> drop one of the transaction and block the database forever (as it is
> happening now). Instead, it could be serialized such that two $100
> transactions are committed to the db.
A situation in whic
Can this situation be handled in sqlite - by upgrading the lock to a
writer lock ? Since both applications use the same WAL file for read and
writes, it shouldnt be a problem , because all changes will be in linear
sequence ?
Sreekumar
On Fri, Feb 10, 2012 at 10:49 PM, Sreekumar TP wrote:
>
> On 2/10/2012 9:57 AM, Sreekumar TP wrote:
>
>> The last transaction should always be the final one. In a a
>> multiprocess/threaded application how can one make assumptions on the
>> order
>> of updates?
SQL does not have any concept of 'last transaction' or 'final transaction' or
'order of tr
Though the example of $ is very intuitive, I am not suggesting that we
drop one of the transaction and block the database forever (as it is
happening now). Instead, it could be serialized such that two $100
transactions are committed to the db.
On Fri, Feb 10, 2012 at 10:33 PM, Igor Tandetnik wr
On 2/10/2012 11:45 AM, Sreekumar TP wrote:
There is no recovery from this situation-
If you try to rollback, you get the following error -"cannot rollback
savepoint, SQL statments in progress" or if you dont use SAVEPOINT -
"cannot rollback, no transaction is active"
If you start the transactio
On 2/10/2012 9:57 AM, Sreekumar TP wrote:
The last transaction should always be the final one. In a a
multiprocess/threaded application how can one make assumptions on the order
of updates?
There are two updates in my example:
update t set count = count + 1;
update t set count = count + 10;
D
On 10 Feb 2012, at 4:45pm, Sreekumar TP wrote:
> There is no recovery from this situation-
>
> If you try to rollback, you get the following error -"cannot rollback
> savepoint, SQL statments in progress" or if you dont use SAVEPOINT -
> "cannot rollback, no transaction is active "
> If you sta
There is no recovery from this situation-
If you try to rollback, you get the following error -"cannot rollback
savepoint, SQL statments in progress" or if you dont use SAVEPOINT -
"cannot rollback, no transaction is active "
If you start the transaction with BEGIN IMMEDIATE in App1, the writer i
On 10 Feb 2012, at 3:01pm, Marc L. Allen wrote:
> From my background, I'm used to SQL statements blocking until appropriate
> locks are acquired. From what I've seen, it looks like sqlite doesn't block,
> but returns BUSY, is that correct?
You can set a timeout. SQLite tries and retries unti
und them.)
>
> Thanks
>
> > -Original Message-
> > From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-
> > boun...@sqlite.org] On Behalf Of Marc L. Allen
> > Sent: Friday, February 10, 2012 9:45 AM
> > To: General Discussion of SQLite Database
&g
haven't found them.)
Thanks
> -Original Message-
> From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-
> boun...@sqlite.org] On Behalf Of Marc L. Allen
> Sent: Friday, February 10, 2012 9:45 AM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] D
The last transaction should always be the final one. In a a
multiprocess/threaded application how can one make assumptions on the order
of updates?
Sreekumar
On Fri, Feb 10, 2012 at 8:16 PM, Igor Tandetnik wrote:
> Sreekumar TP wrote:
> > How is this different from two threads each with a db
Sreekumar TP wrote:
> How is this different from two threads each with a db connection in a
> single process?
If each thread uses its own separate connection, it should be no different -
you would observe the same issue.
> Moreover the journal mode is WAL. Hence the writer should be able to app
February 10, 2012 9:43 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Database locked in multi process scenario
>
> Marc L. Allen wrote:
> > I see. So, the implied commit doesn't occur until you finalize?
>
> Or reset.
>
> > As a result, the su
on't hit a BUSY.
>
> > -Original Message-
> > From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-
> > boun...@sqlite.org] On Behalf Of Richard Hipp
> > Sent: Friday, February 10, 2012 9:28 AM
> > To: General Discussion of SQLite Database
> > Subjec
Marc L. Allen wrote:
> I see. So, the implied commit doesn't occur until you finalize?
Or reset.
> As a result, the subsequent update in step 5 was added to his
> non-finalized select?
The update was attempted within the same transaction.
> Still.. what is the correct way to handle the expli
ruary 10, 2012 9:28 AM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] Database locked in multi process scenario
>
> On Fri, Feb 10, 2012 at 9:19 AM, Marc L. Allen
> wrote:
>
> >
> > So, you're assuming the OP actually started a transaction? B
you're saying that this causes a problem if App2 gets in
> between App1's SELECT and UPDATE?
>
> > -Original Message-
> > From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-
> > boun...@sqlite.org] On Behalf Of Richard Hipp
> > Sent: Friday, Februar
d Hipp
> Sent: Friday, February 10, 2012 9:13 AM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] Database locked in multi process scenario
>
> On Fri, Feb 10, 2012 at 9:05 AM, Rob Richardson con.com>wrote:
>
> > Isn't it almost a requirement of a
012 8:52 AM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] Database locked in multi process scenario
>
> In the real code, there is no sleep/wait or pause. It so happens that the
> write of the app2 is scheduled in between.
>
> What you are suggesting
t; > To: General Discussion of SQLite Database
> > Subject: Re: [sqlite] Database locked in multi process scenario
> >
> >
> > On 10 Feb 2012, at 1:52pm, Sreekumar TP wrote:
> >
> > > In the real code, there is no sleep/wait or pause. It so happens that
>
Sent: Friday, February 10, 2012 8:52 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Database locked in multi process scenario
In the real code, there is no sleep/wait or pause. It so happens that the write
of the app2 is scheduled in between.
What you are suggesting is that a
ze.
> -Original Message-
> From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-
> boun...@sqlite.org] On Behalf Of Simon Slavin
> Sent: Friday, February 10, 2012 8:55 AM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] Database locked in multi proce
On 10 Feb 2012, at 1:52pm, Sreekumar TP wrote:
> In the real code, there is no sleep/wait or pause. It so happens that the
> write of the app2 is scheduled in between.
>
> What you are suggesting is that at any point of time only one process can
> have a transaction open in a database?
I unders
In the real code, there is no sleep/wait or pause. It so happens that the
write of the app2 is scheduled in between.
What you are suggesting is that at any point of time only one process can
have a transaction open in a database?
Sreekumar
On Feb 10, 2012 7:12 PM, "Simon Slavin" wrote:
>
> On
On 10 Feb 2012, at 1:32pm, Sreekumar TP wrote:
> well, the 'wait' is a simulation of what happens in the real code.
>
> The error is fatal to the application as it never ever recovers from it
> even though the writer has finalized and terminated.
In a multi-process environment I recommend that
Hi Simon,
well, the 'wait' is a simulation of what happens in the real code.
The error is fatal to the application as it never ever recovers from it
even though the writer has finalized and terminated.
Sreekumar
On Feb 10, 2012 6:57 PM, "Simon Slavin" wrote:
>
> On 10 Feb 2012, at 11:47am, Sre
On 10 Feb 2012, at 11:47am, Sreekumar TP wrote:
> I have a 'database is locked' issued which can be reproduced as follows.
>
> I have two applications opening the database in WAL mode. The threading
> mode is SERIALIZED. Environment is PC/Linux.
>
>
>
> Step1: Launch App1 followed by App 2
How is this different from two threads each with a db connection in a
single process?
Moreover the journal mode is WAL. Hence the writer should be able to append
changes to the WAL file as there are no other write transaction.
Sreekumar
On Feb 10, 2012 6:22 PM, "Richard Hipp" wrote:
> On Fri, F
On Fri, Feb 10, 2012 at 6:47 AM, Sreekumar TP wrote:
> I have a 'database is locked' issued which can be reproduced as follows.
>
> I have two applications opening the database in WAL mode. The threading
> mode is SERIALIZED. Environment is PC/Linux.
>
>
>
> Step1: Launch App1 followed by App 2
38 matches
Mail list logo
