ehalf of Pavel Ivanov
> Sent: Tue 5/18/2010 12:37 PM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] read only databases and in-memory databases
>
>
>
>> Actually I wonder if the sqlite3 mutex calls would be better yet.
>> http://www.sqlite.org/c3ref/m
ep2 er...@%d: %d, %s\n", j, ret,
sqlite3_errmsg (db));
usleep (1);
}
} while (ret != SQLITE_DONE);
if (busy && 0x08)
usleep (1);
}
fprintf (stderr, "nbusy2=%d \n", nbusy);
waitpid (pid, 0, 0);
On Tue, May 18, 2010 at 12:50:20PM -0500, Black, Michael (IS) scratched on the
wall:
> Rats on the interprocess locks.
More to the point, database connection mutexes are just for the
database connection. Even the same process with more than one
database connection might fight with each oth
18/2010 12:37 PM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] read only databases and in-memory databases
>
>
>
>> Actually I wonder if the sqlite3 mutex calls would be better yet.
>> http://www.sqlite.org/c3ref/mutex_alloc.html
>
> They work onl
Senior Scientist
Northrop Grumman Mission Systems
From: sqlite-users-boun...@sqlite.org on behalf of Pavel Ivanov
Sent: Tue 5/18/2010 12:37 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] read only databases and in-memory databases
> Actuall
> possible?
>
> Michael D. Black
> Senior Scientist
> Northrop Grumman Mission Systems
>
>
>
>
> From: sqlite-users-boun...@sqlite.org on behalf of Simon Slavin
> Sent: Tue 5/18/2010 11:49 AM
> To: General Discussion of SQLite Database
> S
l D. Black
Senior Scientist
Northrop Grumman Mission Systems
From: sqlite-users-boun...@sqlite.org on behalf of Simon Slavin
Sent: Tue 5/18/2010 11:49 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] read only databases and in-memory databases
On 18 May 2010, at 4:19pm, Black, Michael (IS) wrote:
> Interesting...but that logic means that later processes might get their
> results before earlier ones.
There is no harm in this. In fact it's a characteristic of parallel systems.
If it truly mattered which order the results arrived in,
On Tue, May 18, 2010 at 10:19:32AM -0500, Black, Michael (IS) scratched on the
wall:
> Interesting...but that logic means that later processes might get
> their results before earlier ones.
Yes, but that's true regardless. We're talking about parallel
operation on what may or may not be MP/M
> From: sqlite-users-boun...@sqlite.org on behalf of Sam Carleton
> Sent: Tue 5/18/2010 9:57 AM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] read only databases and in-memory databases
>
>
>
> On Tue, May 18, 2010 at 7:35 AM, Black, Michael (IS) >
-boun...@sqlite.org on behalf of Sam Carleton
Sent: Tue 5/18/2010 9:57 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] read only databases and in-memory databases
On Tue, May 18, 2010 at 7:35 AM, Black, Michael (IS) wrote:
> I think I see a potential problem with your logic. You
On Tue, May 18, 2010 at 7:35 AM, Black, Michael (IS) wrote:
> I think I see a potential problem with your logic. You say "up to 2
> seconds" and "up to 4 times". So it sounds like you're doing a 500ms sleep
> on your retry with 4 tries?
>
Actually no, not just 4 retries. What I did was use so
2010 3:46 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] read only databases and in-memory databases
On Mon, May 17, 2010 at 2:27 PM, Black, Michael (IS) wrote:
> Not rude -- just a communications problem...
>
> There's a difference between read-only and exclusive
On 17 May 2010, at 9:46pm, Sam Carleton wrote:
> On Mon, May 17, 2010 at 2:27 PM, Black, Michael (IS) > wrote:
>
>> Not rude -- just a communications problem...
>>
>> There's a difference between read-only and exclusive.
>>
>> Read-only just means you can't do inserts and creates. It's not th
On Mon, May 17, 2010 at 2:27 PM, Black, Michael (IS) wrote:
> Not rude -- just a communications problem...
>
> There's a difference between read-only and exclusive.
>
> Read-only just means you can't do inserts and creates. It's not the write
> mode of the database that matters. It's the transa
On Mon, May 17, 2010 at 02:15:09PM -0400, Sam Carleton scratched on the wall:
> Michael,
>
> I really don't mean to be rude, but I know about the SQLITE_BUSY and that it
> must be handled and all that good stuff, am I handling it right now? No;
> will I? Yes, but that isn't my issue, I understand
here...but I believe this is the way
it works.
Michael D. Black
Senior Scientist
Northrop Grumman Mission Systems
From: sqlite-users-boun...@sqlite.org on behalf of Sam Carleton
Sent: Mon 5/17/2010 1:15 PM
To: General Discussion of SQLite Database
Subject: Re: [sq
__
>
> From: sqlite-users-boun...@sqlite.org on behalf of Sam Carleton
> Sent: Mon 5/17/2010 9:04 AM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] read only databases and in-memory databases
>
>
>
> On Mon, May 17, 2010 at 9:32
sers-boun...@sqlite.org on behalf of Sam Carleton
Sent: Mon 5/17/2010 9:04 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] read only databases and in-memory databases
On Mon, May 17, 2010 at 9:32 AM, Black, Michael (IS) wrote:
> Well...you don't say what "problem
On Mon, May 17, 2010 at 9:32 AM, Black, Michael (IS) wrote:
> Well...you don't say what "problem" your customers are having. Would be
> nice to know for us to help you.
>
At this point in time I am purely theorizing, the client is seeing a break
down in communications between the Silverlight ap
__
From: sqlite-users-boun...@sqlite.org on behalf of Sam Carleton
Sent: Mon 5/17/2010 8:10 AM
To: General Discussion of SQLite Database
Subject: [sqlite] read only databases and in-memory databases
Current situation:
1. Open a DB for read/write
2. Create a temp table
3. Read da
Current situation:
1. Open a DB for read/write
2. Create a temp table
3. Read data from outside source and put into the temp table
4. Do a join on the temp table and another table in the DB
5. Return results
This is happening a lot, and it might be the cause customers are having
pr
22 matches
Mail list logo
