Use a queue for the database operations in this case. You won't suffer from lock or busy errors, if all access is serialized. Queues can scale very well if done right.
Mike -----Ursprüngliche Nachricht----- Von: Gussimulator [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 12. Juli 2006 20:55 An: sqlite-users@sqlite.org Betreff: Re: [sqlite] Problems with Multi-Threaded Application. I cannot delay my thread. Also, if I made a thread per event, then that wouldnt work either, since every thread would open the database to try a write on it. We are talking about 100 events in a second. This thread handles the queries as it gets the events. ----- Original Message ----- From: "Jay Sprenkle" <[EMAIL PROTECTED]> To: <sqlite-users@sqlite.org> Sent: Wednesday, July 12, 2006 2:57 PM Subject: Re: [sqlite] Problems with Multi-Threaded Application. > On 7/12/06, Gussimulator <[EMAIL PROTECTED]> wrote: >> >> About the "cant read while writing", how to avoid this?, I cant stop my >> system while using the database. There would be no point on having a >> database then. > > check the return code from operation, if it says Busy, or Locked, > the redo the operation. You may need to retry several times > > // here's an example with a 1/2 second delay: > sqlite3_busy_timeout(db, 500); > bool locked = true; > for ( int i = 0; ( i < 10 ) && ( locked ); i++ ) > switch ( sqlite3_step() ) > { > case SQLITE_BUSY: > case SQLITE_LOCKED: > break; > case SQLITE_ROW: > case SQLITE_DONE: > locked = false; > break; > default: > throw Exception( "Cannot execute sql" ); > break; > }
