On Mon, 2005-09-05 at 18:36 +0200, Tobias Rundström wrote: > How "expensive" is it to open a new sqlite3 handler?
The schema has to be read and parsed. Usually that is very quick - SQLite has an efficient parser and can process tens of thousands of SQL statements per second. > This seems to occur when this happens: > > thread1: begin > thread2: begin > thread1: insert () > thread2: select () -> EBUSY > thread1: commit -> EBUSY > > to solve this you have to rollback thread2 before you can commit > thread1. It was a strange behaviour that didn't fit my code at all so I > reverted to not using transactions, this works well but probably hurt my > preformance. > > Is there a better way to handle this? > The BEGIN statement defers locks until they are needed. If you do BEGIN EXCLUSIVE instead of just BEGIN, it acquires the locks immediately and would thus cause the EBUSY error when thread2 did its BEGIN. This simplifies recovery at the price of some concurrency. -- D. Richard Hipp <[EMAIL PROTECTED]>
