I came across some OS's over the years which implemented file locks as a
single global lock. Yours may do that.
Mark Brown wrote:
Hi John-
There is a .lock file for each database. From my understanding, that should
prohibit 2 connections from using the same database at the same time.
"As recommended, BEGIN IMMEDIATE should prevent thread2 from even
starting a transaction if thread1 did so first, however I think this
will only work correctly if the same connection handle is used in both,
else they still may not know about eachother."
Simply not true... If you
If they are different files then you should not have any of these
problems.
-Original Message-
From: RaghavendraK 70574 [mailto:[EMAIL PROTECTED]
Sent: 16 August 2007 11:21 AM
To: sqlite-users@sqlite.org
Subject: Re: RE: [sqlite] SQLITE_BUSY error in multi-threaded
environment
hi,
Am
<[EMAIL PROTECTED]>
Date: Thursday, August 16, 2007 4:36 pm
Subject: RE: [sqlite] SQLITE_BUSY error in multi-threaded environment
> Ok well I guess I forgot to mention this is what has made me want to
> pull my hair out a few times :) the fact that you have to worry about
> both sc
Hope this helps
-Original Message-
From: Mark Brown [mailto:[EMAIL PROTECTED]
Sent: 15 August 2007 04:34 PM
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] SQLITE_BUSY error in multi-threaded environment
Hi Andre-
After rereading your post, I wanted to confirm something. In your
example
ust 15, 2007 12:39 PM
> To: sqlite-users@sqlite.org
> Subject: RE: [sqlite] SQLITE_BUSY error in multi-threaded environment
>
>
> It should not.
>
> As long as those two connections are not used across threads
> and point to truely different databases.
>
&g
gt; Subject: RE: [sqlite] SQLITE_BUSY error in multi-threaded environment
>
>
> It should not.
>
> As long as those two connections are not used across threads
> and point to truely different databases.
>
> The
It should not.
As long as those two connections are not used across threads and point to
truely different databases.
They wouldn't be a soft link would they? I
Mark Brown <[EMAIL PROTECTED]> wrote: Hi John-
There is a .lock file for each database. From my understanding, that should
--- Mark Brown <[EMAIL PROTECTED]> wrote:
> There is a .lock file for each database. From my understanding, that should
> prohibit 2 connections from using the same database at the same time.
> However, that is not the situation I am wondering about. I am specifically
> wondering if database
Hi John-
There is a .lock file for each database. From my understanding, that should
prohibit 2 connections from using the same database at the same time.
However, that is not the situation I am wondering about. I am specifically
wondering if database activity on a connection to DB 1 would have
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 15, 2007 5:05 AM
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] SQLITE_BUSY error in multi-threaded environment
Being a newbie to SQLite I've had the same problems working
with SQLite
so maybe I can help,
It does not matter how well your
> -Original Message-
> From: Andre du Plessis [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 15, 2007 5:05 AM
> To: sqlite-users@sqlite.org
> Subject: RE: [sqlite] SQLITE_BUSY error in multi-threaded environment
>
>
> Being a newbie to SQLite I've had t
ct: RE: [sqlite] SQLITE_BUSY error in multi-threaded environment
>
>
> Being a newbie to SQLite I've had the same problems working
> with SQLite
> so maybe I can help,
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
Being a newbie to SQLite I've had the same problems working with SQLite
so maybe I can help,
It does not matter how well your database is synchronized, a common
pitfall I had was that I would have a query object with an open cursor
which prevents any other statement from committing to the
14 matches
Mail list logo
