Re: [sqlite] Shared Cache vs. Serialized

Keith Medcalf wrote > See also Write Ahead Logging journal mode (WAL) where in the case you > specified B's operation will succeed even if it is updating a table being > read by connection A. Oh, good to know! For anyone who stumbles across this thread in the future, note that this requires that

Re: [sqlite] Shared Cache vs. Serialized

>Another interesting distinction between shared and private cache mode >I found while experimenting. Ordinarily if connection A is in the >middle of fetching result rows from a SELECT (i.e., sqlite3_step was called, >but not sqlite3_reset), and connection B tries to do a CREATE/UPDATE/DELETE, >B w

Re: [sqlite] Shared Cache vs. Serialized

Jens Alfke-2 wrote > But since the connections are sharing a cache, they still end up seeing > uncommitted writes. I believe this is managed by the read_uncommitted pragma . Another interesting distinction between shared and private c

Re: [sqlite] Shared Cache vs. Serialized

> On Dec 30, 2018, at 7:52 AM, Jesse Rittner wrote: > > It > seems to me that there are two ways we can have multiple threads all > accessing a database via a "single" connection. Actually there is at least one more way: Create a global connection pool. When a thread needs to access the datab

Re: [sqlite] Shared Cache vs. Serialized

> On Dec 30, 2018, at 7:52 AM, Jesse Rittner wrote: > > One, establish a single > serialized private cache connection up front, and give it to all the > threads. Two, have each thread independently establish a multi-thread shared > cache connection. What are the trade-offs between these two app

Re: [sqlite] Shared Cache vs. Serialized

The "normal" connection mode would be to have a separate connection for each thread, with no shared cache. Each connection is opened with the FULLMUTEX (serialized) flags. This is the default. Each connection is fully isolated from every other connection. Assuming that each "thread" has its

Re: [sqlite] shared cache mode and 'LOCKED'

ifying this. Owen. -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of John Crenshaw Sent: Thursday, October 29, 2009 5:49 AM To: General Discussion of SQLite Database Subject: Re: [sqlite] shared cache mode and 'LOCKED

Re: [sqlite] shared cache mode and 'LOCKED'

at clarify this? John -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Tom Broadbent Sent: Wednesday, October 28, 2009 6:33 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] shared cache mode and 'LOCKED'

Re: [sqlite] shared cache mode and 'LOCKED'

lite-users-boun...@sqlite.org] On Behalf Of John Crenshaw Sent: Wednesday, October 28, 2009 12:49 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] shared cache mode and 'LOCKED' Almost. Locking happens at a table level in this case, not a database level. Three different thr

Re: [sqlite] shared cache mode and 'LOCKED'

Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Tom Broadbent Sent: Wednesday, October 28, 2009 3:46 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] shared cache mode and 'LOCKED' oh, right. my bad. i don't

Re: [sqlite] shared cache mode and 'LOCKED'

this right? -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of John Crenshaw Sent: Wednesday, October 28, 2009 12:38 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] shared cache mode and 'LOCKED'

Re: [sqlite] shared cache mode and 'LOCKED'

aded application, because otherwise contention is too great. John -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Tom Broadbent Sent: Wednesday, October 28, 2009 3:32 PM To: General Discussion of SQLite Database Subject: Re: [sqli

Re: [sqlite] shared cache mode and 'LOCKED'

: Wednesday, October 28, 2009 12:32 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] shared cache mode and 'LOCKED' to be clear... "in other words, two threads sharing a connection in shared cache mode will always cause SQLITE_LOCKED (rather than SQLITE_BUSY)

Re: [sqlite] shared cache mode and 'LOCKED'

_BUSY will be returned." i believe this is correct. experts? -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Tom Broadbent Sent: Wednesday, October 28, 2009 12:27 PM To: General Discussion of SQLite Database Subject: R

Re: [sqlite] shared cache mode and 'LOCKED'

i'm no expert on this, but my understanding is that since shared cache mode 'shares a connection' you won't get SQLITE_BUSY but rather SQLITE_LOCKED since the contention is 'internal' to the connection. in other words, two threads sharing a connection in shared cache mode will always cause SQLI

Re: [sqlite] shared cache mode and 'LOCKED'

It appears to be up to date. John -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of O'Neill, Owen Sent: Wednesday, October 28, 2009 1:45 PM To: General Discussion of SQLite Database Subject: [sqlite] shared cache mode and 'LOCKE

Re: [sqlite] Shared Cache unlock notification to multiple threads

On Mar 23, 2009, at 5:45 AM, Edzard Pasma wrote: > Hello, > > The new sqlite3_unlock_notify API, described in > http://www.sqlite.org/draft/c3ref/unlock_notify.html > and expected in SQLite 3.6.12, may have a restriction for use when > multiple threads share the same connection. The document

Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step()

can be interpreted the same as SQLITE_BUSY? > > Cheers, > Dave. > > > -Original Message- > From: Hynes, Tom [mailto:tom.hy...@inin.com] > Sent: 06 March 2009 05:10 > To: General Discussion of SQLite Database > Subject: Re: [sqlite] shared cache and SQLITE_M

Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step()

: 06 March 2009 05:10 To: General Discussion of SQLite Database Subject: Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step() Thanks Dan! -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Dan Sent: Thursday, March 05

Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step()

Thanks Dan! -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Dan Sent: Thursday, March 05, 2009 10:08 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step() On Mar

Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step()

On Fri, 06 Mar 2009 10:26:38 +0100, Marcus Grimm wrote: >The website is allready excellent, I'm not at all complaining... > >Anyway, I've placed an updated version of the thread test program on the >web: > >http://www.exomio.de/sqlitethreadtest.c > >If somebody found it useful or good enough: Fee

Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step()

Dan wrote: > On Mar 6, 2009, at 1:48 PM, Marcus Grimm wrote: > >> I just want to add another hint that I learned yesterday: >> >> when sqlite3_step() returns SQLITE_LOCKED be aware >> that sqlite3_reset() will most likely also return >> SQLITE_LOCKED and thus it is necessary to repeat calling >>

Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step()

On Mar 6, 2009, at 1:48 PM, Marcus Grimm wrote: > I just want to add another hint that I learned yesterday: > > when sqlite3_step() returns SQLITE_LOCKED be aware > that sqlite3_reset() will most likely also return > SQLITE_LOCKED and thus it is necessary to repeat calling > it until it returns S

Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step()

t;> >> Tom >> >> -Original Message- >> From: sqlite-users-boun...@sqlite.org >> [mailto:sqlite-users-boun...@sqlite.org >> ] On Behalf Of Dan >> Sent: Thursday, March 05, 2009 12:38 PM >> To: General Discussion of SQLite Database >> Sub

Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step()

e.org [mailto:sqlite-users-boun...@sqlite.org > ] On Behalf Of Dan > Sent: Thursday, March 05, 2009 12:38 PM > To: General Discussion of SQLite Database > Subject: Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step() > > > On Mar 6, 2009, at 12:22 AM, Marcus Grimm wrote:

Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step()

-boun...@sqlite.org] On Behalf Of Dan Sent: Thursday, March 05, 2009 12:38 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step() On Mar 6, 2009, at 12:22 AM, Marcus Grimm wrote: > Dan, > > I'm not sure what you mean by t

Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step()

the magic MISSUSE. >>>>>> >>>>>> Yes, I also tried to call sqlite_reset right >>>>>> after this first error and in this case >>>>>> sqlite_reset return the LOCK state. I didn't >>>>>> yet go on to handl

Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step()

;>>>>> simplify the code given below. My original code >>>>>>> checks that and it usually works quite well. >>>>>>> that's basically the reason why I was puzzled >>>>>>> by the randomly MISUSE results

Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step()

one runs >>>> without any problem, it's my fault, if not: I'll post >>>> it here for further discussions... ;) >>>> >>>> Thanks for your feedback >>>> >>>> Marcus >>>> >>>> >>>>> Marc

Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step()

post >>> it here for further discussions... ;) >>> >>> Thanks for your feedback >>> >>> Marcus >>> >>> >>>> Marcus, >>>> >>>> I'm not sure if this will help or not... >>>> >>>

Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step()

noticed your sample code does not test the return value from >>> the >>> sqlite3_prepare_v2 call. Could the code be entering the do loop >>> when an >>> error was returned from prepare? >>> >>> Just an idea. >>> >>>

Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step()

call. Could the code be entering the do loop when an >> error was returned from prepare? >> >> Just an idea. >> >> Have you tried the reset call as DRH had suggested? >> Your prior post indicated you had more code and another loop. Can you post >> the fu

Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step()

; HTH > > > > --- On Wed, 3/4/09, Marcus Grimm wrote: > >> From: Marcus Grimm >> Subject: Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step() >> To: kennethinbox-sql...@yahoo.com, "General Discussion of SQLite >> Database" >> Date: Wednes

Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step()

ested? Your prior post indicated you had more code and another loop. Can you post the full code for both loops? HTH --- On Wed, 3/4/09, Marcus Grimm wrote: > From: Marcus Grimm > Subject: Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step() > To: kennethinbox-sql...@yahoo

Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step()

. > > > --- On Wed, 3/4/09, Marcus Grimm wrote: > >> From: Marcus Grimm >> Subject: Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step() >> To: "General Discussion of SQLite Database" >> Date: Wednesday, March 4, 2009, 10:25 AM >

Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step()

wrote: > From: Marcus Grimm > Subject: Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step() > To: "General Discussion of SQLite Database" > Date: Wednesday, March 4, 2009, 10:25 AM > Richard, thanks again for the feedback. > > However, I don&#x

Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step()

Richard, thanks again for the feedback. However, I don't see how it can happend that the statement is completed internally without returning SQLITE_DONE. In the particular code of the "reading thread" I do something like: -- sqlite3_prepare_v2(db, "SELECT * FROM TableA", -1, &stmt, 0); /** step t

Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step()

On Mar 4, 2009, at 9:35 AM, Marcus Grimm wrote: > hi, > > OK, the value of p->magic is 519C2973 (VDBE_MAGIC_HALT) That means the prepared statement has run to completion and needs to be reset using sqlite3_reset() before you continue. D. Richard Hipp d...@hwaci.com

Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step()

hi, OK, the value of p->magic is 519C2973 (VDBE_MAGIC_HALT) that should mean that "VDBE has completed execution"... I don't know... in that case I should get a SQLITE_DONE when stepping throu the result set, right ? Just some additional info: It is the last sqlite version, threadsafe is true an

Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step()

On Mar 4, 2009, at 8:31 AM, Marcus Grimm wrote: > Richard, > Thanks for looking into this. > > I've placed some debug output in the sqlite2_step function > and I found that it returns SQLITE_MISUSE here: > > -- > static int sqlite3Step(Vdbe *p){ > sqlite3 *db; > int rc; > > assert(p); >

Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step()

Richard, Thanks for looking into this. I've placed some debug output in the sqlite2_step function and I found that it returns SQLITE_MISUSE here: -- static int sqlite3Step(Vdbe *p){ sqlite3 *db; int rc; assert(p); if( p->magic!=VDBE_MAGIC_RUN ) { return SQLITE_MISUSE; }

Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step()

On Mar 4, 2009, at 5:19 AM, Marcus Grimm wrote: > Hi all, > > I'm doing a little stress test on a server application and run into > a problem when two threads are trying to access the database. > Here is the background: > 1. shared cache is enabled prior open any DB connection. > 2. Each thread t

Re: [sqlite] shared cache and journal files

It's funny how explaining an issue to a mailing list can make you spot the problem yourself... there was indeed a problem with my test code, database connections were not being opened for every thread as I expected them to be. I love SQLite - the bug is always in my code :) Cheers, Dave. -O

Re: [sqlite] shared cache and journal files

A little more detail on this issue: It seems that my reading thread is not getting a shared lock on the database before accessing the journal file. In pagerSharedLock() the shared-cache Pager state is already PAGER_EXCLUSIVE because another thread is writing to a different table in the same databa

Re: [sqlite] Shared cache clarification.

Excellent, that's what I was hoping for. Thanks, Dan! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Sent: Wednesday, October 22, 2008 5:54 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] Shared cache clarification. On O

Re: [sqlite] Shared cache clarification.

On Oct 22, 2008, at 11:32 PM, Hynes, Tom wrote: > Hello, > > > > I noticed that the documentation for PRAGMA read_uncommitted in > http://www.sqlite.org/pragma.html says: > > > > "...Cache sharing is enabled using the sqlite3_enable_shared_cache() >

Re: [sqlite] Shared cache benefit question

Just give it a try and see what happens. You just need to enable the shared cache once. I'd think the blocking would not be any different with the shared cache enabled. But you should get reduced I/O load since the cache will be larger and accessible to all threads. HTH, Ken D

Re: [sqlite] Shared Cache for Processes

Hi, Speaking only as a non-professional, I still try to answer. I don't want to comment on the benefits of shared cache mode now, but only on the question if it can be enabled in Apache. And I believe it can. As you say Apache pre-forks different processes, but within each process it pre-

Re: [sqlite] shared cache and 'no such table' issue

On Dec 27, 2007 10:15 PM, Dan <[EMAIL PROTECTED]> wrote: > Should be fixed by: > >http://www.sqlite.org/cvstrac/chngview?cn=4643 > > Please post if you find this is not the case (or if you find it is). > It fixes the problem. Thanks a lot for your help. Jay -

Re: [sqlite] shared cache and 'no such table' issue

On Dec 27, 2007, at 5:51 PM, Pathompong Puengrostham wrote: I think I found a bug in sqlite3_close but don't know how to fix it. There is a race condition between sqlite3SchemaFree and sqlite3Init. The problem is if there are two threads with its own connection to the same database file with sh

Re: [sqlite] shared cache and 'no such table' issue

I think I found a bug in sqlite3_close but don't know how to fix it. There is a race condition between sqlite3SchemaFree and sqlite3Init. The problem is if there are two threads with its own connection to the same database file with shared-cache mode enabled. Db.pSchema of both connections point to

Re: [sqlite] shared cache and 'no such table' issue

I found that the sqlite3_open call is not thread safe even if you open different files in separate connections. Cannot tell you about sqlite3_close but may be the same problem. Darío On Dec 26, 2007 6:40 AM, Pathompong Puengrostham <[EMAIL PROTECTED]> wrote: > Hi, > > I have a multi-threaded progr

Re: [sqlite] shared cache mode locking

So did my post. We are talking about the same thing. Definately confusing, at least to me.. The problem exists wherein you have two shared connections and one connection performs a begin exclusive... The other connection was just ignoring the exclusivity lock and continuing on its merry way and

Re: [sqlite] shared cache mode locking

No, you did not confuse me. We are talking about different things it appears. My post refers to the shared-cache locking model (http:// sqlite.org/sharedcache.html). The document is clear by itself. What makes it confusing, is that a shared cache instance exist as a single normal connection

Re: [sqlite] shared cache mode locking

Ed, Sorry if I confused you, a "Write" lock is really an EXCLUSIVE lock per sqlite documentation. I used the two interchangeably, pardon my error. A begin exclusive indicates the beginning of a transaction, It escalates the database lock to an EXCLUSIVE lock. The begin transaction does not imme

Re: [sqlite] shared cache mode locking

The ticket has already been resolved, I see. So it has been considered a bug. In my earlier reply I tried to defend the current behavour to be in line with the document, http://sqlite.org/ sharedcache.html. I'm happy to change my mind now. Only I miss something in the model as described in t

Re: [sqlite] shared cache mode locking

Ed, Dan opened a ticket. I agree the documentation isn't clear on the Exlusive locking state. Not really sure, if this is by design or a bug at this stage. I do think its a great feature of the Shared cache mode to allow table level locking. But I'm curious with this table level locking what

Re: [sqlite] shared cache mode locking

Hello,` Empirically I found that it is exactly true. Must admit I'm confused but may it is in line with the Shared-Cache locking model. This does not mention the EXCLUSIVE locking state. The most 'secure' locking state it mentions is a write-transaction and this can coexist with read-transact

Re: [sqlite] shared cache mode locking

Some additional info: when the sqlite_lock is returned there is another thread that appears to be reading the same table. Does the sqlite3 step return sqlite_locked in this case? Thanks, Ken Ken <[EMAIL PROTECTED]> wrote: While using the new 3.5.4 sqlite3_enable_shared_cache I ran into a

Re: [sqlite] shared cache/ test_server.c

Scott Hess wrote: On 7/27/07, John Stanton <[EMAIL PROTECTED]> wrote: Scott Hess wrote: On 7/26/07, Richard Klein <[EMAIL PROTECTED]> wrote: According to the Mozilla article referenced above, it's even worse than that: *All* cache pages, dirty or not, are freed at the end of *every* transa

Re: [sqlite] shared cache/ test_server.c

On 7/27/07, John Stanton <[EMAIL PROTECTED]> wrote: > Scott Hess wrote: > > On 7/26/07, Richard Klein <[EMAIL PROTECTED]> wrote: > >>According to the Mozilla article referenced above, it's even worse than > >>that: *All* cache pages, dirty or not, are freed at the end of *every* > >>transaction, e

Re: [sqlite] shared cache/ test_server.c

Scott Hess wrote: On 7/26/07, Richard Klein <[EMAIL PROTECTED]> wrote: According to the Mozilla article referenced above, it's even worse than that: *All* cache pages, dirty or not, are freed at the end of *every* transaction, even if the transaction consisted of only read operations. I bel

Re: [sqlite] shared cache/ test_server.c

Richard Klein wrote: John Stanton wrote: Richard Klein wrote: Joe Wilson wrote: You've probably read this. It's useful information for any performance minded developer using SQLite: http://developer.mozilla.org/en/docs/Storage:Performance >> [snip] If the above is correct, it

Re: [sqlite] shared cache/ test_server.c

On 7/26/07, Richard Klein <[EMAIL PROTECTED]> wrote: > According to the Mozilla article referenced above, it's even worse than > that: *All* cache pages, dirty or not, are freed at the end of *every* > transaction, even if the transaction consisted of only read operations. I believe this is no lo

Re: [sqlite] shared cache/ test_server.c

John Stanton wrote: Richard Klein wrote: Joe Wilson wrote: You've probably read this. It's useful information for any performance minded developer using SQLite: http://developer.mozilla.org/en/docs/Storage:Performance >> [snip] If the above is correct, it is not enough for the serve

Re: [sqlite] shared cache/ test_server.c

Richard Klein wrote: Joe Wilson wrote: You've probably read this. It's useful information for any performance minded developer using SQLite: http://developer.mozilla.org/en/docs/Storage:Performance I read it, and I'm now weeping! Below I've reproduced the paragraphs that cause me some c

Re: [sqlite] shared cache/ test_server.c

Joe Wilson wrote: You've probably read this. It's useful information for any performance minded developer using SQLite: http://developer.mozilla.org/en/docs/Storage:Performance I read it, and I'm now weeping! Below I've reproduced the paragraphs that cause me some consternation:

Re: [sqlite] shared cache/ test_server.c

I read that. The Mozilla people point out that their advantage was with a large volume of small transactions. They benefit from not destroying the cache between transactions and by conserving memory with large numbers of users. They point out that relaxing the ACID requirements also aids thr

Re: [sqlite] shared cache/ test_server.c

> Shared cache mode would be better named "persistent cache mode" because > its main effect is to permit one thread to not flush the cache after > each transaction. The people at Mozilla report that they use it and get > better throughput on small transactions. You've probably read this. It's

Re: [sqlite] shared cache/ test_server.c

Now you have made me worry. If cache can only be shared by connections created in one thread then there is no shared cache. I must investigate this more closely. Perhaps my reading of the documentation included a dose of wishful thinking and a belief that "shared" meant shared! Looking throu

Re: [sqlite] shared cache/ test_server.c

John, According to the Sqlite documentation on sqlite3_enable_shared_cache: "There is no mechanism for sharing cache between database connections running in different threads." This means exactly what I said in the first place: You cannot have a "shared cache" access across threads. I rea

Re: [sqlite] shared cache/ test_server.c

--- John Stanton <[EMAIL PROTECTED]> wrote: > I think that you misunderstood the shared cache description. Cache is > shared by many connections but connections may not be passed between > threads. Each thread must maintain and use its its own connection. In > our case a thread has an associa

Re: [sqlite] shared cache/ test_server.c

I think that you misunderstood the shared cache description. Cache is shared by many connections but connections may not be passed between threads. Each thread must maintain and use its its own connection. In our case a thread has an associated control block and the connection handle resides

Re: [sqlite] shared cache/ test_server.c

Ken wrote: I guess my point was that inside the server thread, once a transaction is entered upon behalf of a client then only that activity may continue and no others. So in my design i only had two choices, re-enqueue the message inside the server until the transactional thread completed or r

Re: [sqlite] shared cache/ test_server.c

John, The server can maintaine a "shared cache" but if a thread also opens the DB then that execution line will not have a "shared cache" but rather a cache per thread. Only the server thread may open and act upon the connection utilizing a shared cache on behalf of the client. The client may

Re: [sqlite] shared cache/ test_server.c

That is why the Sqlite locking is not a good fit for a threaded server. Why not use thread locks instead and achieve the synchronization with minimum overhead and latency? You do miss out on a couple of Sqlite features doing that (the pending and reserved locks which help with concurrency and

Re: [sqlite] shared cache/ test_server.c

John, The sqlite api won't block, it will return a sqlite_busy type error to any other transactions that are attempted? Correct, so there is no sqlite blocking which is a good thing when writing a server. The clients will always block waiting upon a response from the server. The server simply k

Re: [sqlite] shared cache/ test_server.c

Why not just bloock on the transation. That will queue waiting threads, serializing the access to the transaction. Ken wrote: My assumption for the server thread was that it needed to process all incoming requests in transaction order and to not loose outstanding requests. You have two choi

Re: [sqlite] shared cache/ test_server.c

Ken wrote: Richard, You might want to look at src/test_server.c for an example of the shared_cache if you haven't found it already. I'll take a look at it, thanks! Personally, I think it makes a lot of sense (read simpler) to implement independent connections than to implement a server

Re: [sqlite] shared cache/ test_server.c

My assumption for the server thread was that it needed to process all incoming requests in transaction order and to not loose outstanding requests. You have two choices once a client initiates a transaction: a. reject the incoming request since a transaction is active in the server. Th

Re: [sqlite] shared cache/ test_server.c

Ken wrote: Richard, You might want to look at src/test_server.c for an example of the shared_cache if you haven't found it already. Personally, I think it makes a lot of sense (read simpler) to implement independent connections than to implement a server. But I can see why you might want a

Re: [sqlite] shared cache

Richard Klein wrote: [EMAIL PROTECTED] wrote: John Stanton <[EMAIL PROTECTED]> wrote: Yes, each connection has a cache. A lot of concurrent connections means a lot of memory allocated to cache and potentially a lot of duplicated cached items. See shared cache mode for relief. Yes. B

Re: [sqlite] Shared cache mode issue

On Tue, 2007-01-09 at 08:01 -0800, Peter James wrote: > On 1/9/07, Dan Kennedy <[EMAIL PROTECTED]> wrote: > But it looks to me like commit #3341 (August 2006) covers this > up. #3341 > changes things so that the shared-schema is reset whenever any > connection handle

Re: [sqlite] Shared cache mode issue

On 1/9/07, Dan Kennedy <[EMAIL PROTECTED]> wrote: But it looks to me like commit #3341 (August 2006) covers this up. #3341 changes things so that the shared-schema is reset whenever any connection handle is closed, so it's not possible for the pointer in question to go stale. Hey Dan... Tha

Re: [sqlite] Shared cache mode issue

On Mon, 2007-01-08 at 16:03 -0800, Peter James wrote: > Hey folks... > > The context of this message is sqlite library version 3.3.6, using the > shared-cache mode, effectively following the test_server.c example. > Immediately upon switching to shared-cache mode we started seeing errors > like so

Re: [sqlite] Shared cache mode issue

On 1/8/07, Peter James <[EMAIL PROTECTED]> wrote: Thanks for your response, Ken. I'm not sure I've explained myself properly. It's not that I'm calling sqlite3_enable_shared_cache() multiple times. It's that if I don't maintain a persistent connection while the server is running I end up with

Re: [sqlite] Shared cache mode issue

On 1/8/07, Ken <[EMAIL PROTECTED]> wrote: You could always implement a sqlite3_open call and store it in the g variable, and close it when the server quits. Thanks for your response, Ken. I'm not sure I've explained myself properly. It's not that I'm calling sqlite3_enable_shared_cache() mu

Re: [sqlite] Shared cache mode issue

Here is a code snipet from my version if the server thread code I found that it was doing an enable/disable on the shared cache with the original logic. You could always implement a sqlite3_open call and store it in the g variable, and close it when the server quits. void *sqlite3

Re: [sqlite] shared-cache mode and firefox

Thanks Vitali, and Trevor. I'll poke them instead ;) > Firefox is now using sqlite. They use shared-cache mode because they want it > to work over networked drives and they don't want to pay for the > latency involved. The "shared cache mode" in sqlite only changes certain behavior for threads

Re: [sqlite] shared-cache mode and firefox

On 12/6/06, Jay Sprenkle <[EMAIL PROTECTED]> wrote: Firefox is now using sqlite. They use shared-cache mode because they want it to work over networked drives and they don't want to pay for the latency involved. The "shared cache mode" in sqlite only changes certain behavior for threads in the

Re: [sqlite] shared-cache mode and firefox

http://www.sqlite.org/sharedcache.html It's controlled at runtime by the function int sqlite3_enable_shared_cache(int); Thus that behaviour is probably controlled by Firefox (assuming it uses a version of sqlite with cache support compiled in). You'd have to ask them. Jay Sprenkle wrote: G