Hello,
"D. Richard Hipp" <[EMAIL PROTECTED]>
23/11/2003 12:09 AM
To: [EMAIL PROTECTED]
cc:
Subject: [sqlite] Improving concurrency in SQLite
> Feedback is requested on the paper found at:
> http://www.sqlite.org/concurrency.ht
Looking at the feedback paper, I wonder whether, possibly, things are being
made more complicated than necessary.
In most (if not all) of the situations I've seen people mention where
concurrency is a problem (and in our own similar situation), it looks as if
the problem is all in 'single appli
On Sat, 2003-11-22 at 12:02, D. Richard Hipp wrote:
> It is more complicated than that. In order to maintain isolation
> (the "I" in "ACID") the second commit must fail if at any time during
> the transaction it read a value that was written by the first commit,
> or if the first commit read a val
Wow! Thank you for putting the idea on board.
My point of view. Right now I have to use BDE (Borland Databse
Engine). It is slow, small SQL embadden engine, which works on
Paradox / DBase files (I know - many others, but for description
that two is all you need to understand it). I don't like A
Hello everyone,
I strongly agree with Doug. I've been using SQLite in multithreaded,
single process mode, and after reading the draft, I thought that
perhaps another thread could provide a locking service. As Doug states,
this "client-server" environment would allow for finer locking
capabilit
pp [mailto:[EMAIL PROTECTED]
Sent: Sunday, 23 November 2003 1:09 AM
To: [EMAIL PROTECTED]
Subject: [sqlite] Improving concurrency in SQLite
Feedback is requested on the paper found at:
http://www.sqlite.org/concurrency.html
Your analysis and ideas will help to make SQLite a
better database engin
D. Richard Hipp wrote:
Feedback is requested on the paper found at:
Richard,
SQLite is one of my favorite examples of good open-source s/w.
I read (with great interest) your paper, and would not have a problem
with any of the proposals being implemented. All would have some benefits.
However, a
My uses of SQLite are multithreaded (mostly) single process. So, an
approach that would appeal to me is "client-server" where the server
is a thread in my process, and the clients are other threads. Adding
a lock manager to the server thread would permit fine grained locking
with ACID properties.
Mrs. Brisby wrote:
Instead of keeping an "undo" journal- consider using a "changes"
journal-- each writer could use it's own journal then only at commit
would each worker actually start making changes to the database.
> ...
>
Note that these changes will contain not only the values they are
storing
This is more rambling than anything else. I hope I'm reasonably coherent
before coffee...
Instead of keeping an "undo" journal- consider using a "changes"
journal-- each writer could use it's own journal then only at commit
would each worker actually start making changes to the database.
DEFER_W
> Feedback is requested on the paper found at:
>
> http://www.sqlite.org/concurrency.html
>
> Your analysis and ideas will help to make SQLite a
> better database engine. Thanks.
In my somehwhat limited knowledge of database design, I'd advocate all the
options in section 4 (ie transaction o
Feedback is requested on the paper found at:
http://www.sqlite.org/concurrency.html
Your analysis and ideas will help to make SQLite a
better database engine. Thanks.
--
D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
-
12 matches
Mail list logo
