[EMAIL PROTECTED] wrote: Hi,
I am having a scenario where I have one reader/writer and many writer threads. All writers are pretty basic (single INSERT INTO; some sort of a logging info what a thread has done). I believe I will receive many BUSY return codes and I don't like these spinlock-like retries. The problem I am having with this design is that I would like to complete the thread ASAP, so that I don't have many threads idling and consuming resources of my embedded system. I was thinking to either: a. Use mutex/semaphore before writting to the database or b. Have a (thread safe) list of INSERT INTO strings that every writer thread populates and the main reader/writer thread later executes. Is this a good approach? Does anyone have a better design? I don't want to use other database, because I think Sqlite is great for an embedded system that I am using. ___________________________________________________________________________ Najhitrej¹i brezplaèni klicni dostop :: Varno in zanesljivo po internetu Obi¹èite http://www.dialup386.com/ ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] ----------------------------------------------------------------------------- When you have multiple writes using sqlite you will need to perform a syncrhonization of some form. I would recommend using option "b" that you indicated. Create a thread that connects to the DB and handles all of you i/o to sqlite. That way you will never get a db locked or busy retry... Take a look at src/test_server.c for an example implementation. For your case you really don't need to implement the "shared cache". Just create a simple db open internally to the thread. Have each client send its insert data into the "servers" incoming work queue. This will work as long as the "clients" don't need to wait or guarantee durability before proceeding.
