James Gregurich wrote:
> If the sqlite statement had a temporary storage area so that I could
> load up a bunch of rows and then commit them in one shot so that the
> lock on the db was not held very long by a single transaction, that
> would probably work.
>
Using a RAM disk you could insert rows into one database as they are
generated. This would be your batch.
Then periodically attach that database to the main database and copy all
the new rows to the main DB table in one in a auto transaction.
attach "batch.db" as batch;
begin;
insert into main.tbl select * from batch.tbl;
delete from batch.tbl;
commit;
detach batch;
This will only lock the main database for a short period while it is
updated.
> However, my reading of the documentation leads me to believe that
> using the bind functions in a loop with an insert statement will lock
> the entire in-memory DB until the bulk insert is done....which means I
> would get no benefit from concurrency.
>
> Is this correct?
Readers are blocked by a writer until the write transaction is committed.
>
> BTW: does the question I posed on modifying the library to add a
> feature to attach an in-memory data stores to another one via the C
> API belong on the sqlite-dev list?
>
That list doesn't get much traffic. Your question was fine here.
It would be fairly involved to change the handling of in memory
databases. They don't have names to use with the attach command, and
they don't do any locking since they can only be accessed from a single
connection currently. The locking in SQLite is done with POSIX file
locks which can't be used for in memory databases since they aren't
files. You're welcome to try of course, but it seems like a lot of work
for little return when there are other ways to do what you want.
HTH
Dennis Cote
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
