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]>

Reply via email to