[EMAIL PROTECTED] wrote:
Keep It Simple, Keep It Small Foot Print.
If the multi-access, multi writter can be implemented without compromising
these two tenets, then great. Otherwise, let's use a different RDBMS.
Jim Dodgen wrote:
Applications that need many concurrent tasks doing updates might think about using a server based RDBMS that has the added complexity and size for this purpose.
I disagree.sqlite3 is advertised as supporting read/write from multiple threads and multiple
processes (as Uriel says, multi-access, multi-writer) so it should work in such a scenario.
We should not be judging any particular use of sqlite-- if it is used in the wrong way,
performance may suffer, but it should *work*.
In my case, I have a server doing most of the writing, and 0 to several "control consoles"
that do occasional db writes for IPC purposes. That is by no means a complex system,
but as soon as I went from 1 writer to 2, problems started to crop up.
I am very glad to see the change that Dr. Hipp checked in, as I hope it fixes the problem
I reported here: http://www.mail-archive.com/sqlite-users@sqlite.org/msg05621.html
(which I think was lost in the shuffle, either because I didn't open a ticket for it or because
my example wasn't as nice, compact, and obvious as the one on Ticket 1159).
-- Eli Burke
