I think I've confused the issue a bit and the aforementioned time hit might be 
normal given:
http://www.sqlite.org/lockingv3.html 

We are using a separately developed COM DLL interface to Sqlite v3: 
http://www.sqliteplus.com/ 

And we can live with the journal creation time if that is what it is.

Tom

----------------------------------------
 From: [EMAIL PROTECTED]
Sent: Monday, December 19, 2005 6:43 AM
To: sqlite-users@sqlite.org
Subject: [sqlite] multiple Db's and journal file time hit? 

Hello

Recently it was written: whenever a modifying transaction starts (or rather, 
when it 
has to actually write data to disk for the first time), SQLite has to 
create a journal file for each DB involved as well as a master journal 
file. 

We are testing (almost ready to purchase the $180 COM version) and have just 
noticed a 30-40 second hit at early on in our program running. It happens when 
accessing the databases but not always the same call and we are wondering if it 
might be related to journal file start up time OR if there is some kind of 
built-in pause or delay in the demo version. 

Background: 

a) We use two databases- one for a current run and one for long-term history.
b) The historical database has two tables with two indexes (an integer (hash 
code) and a date column) and is set to synchronous = Normal
c) The current-run database has one table with two indexes (an integer (hash 
code) and another integer) and is set to synchronous = OFF. Note: we blow away 
the current-run database each time a certain process is kicked off and there is 
never more than one current-run db-- so if the data is lost from the current 
run it is no big deal.
d) It is a Win32 application and PRAGMA page_size = 4096.
e) System memory is 512MB and PRAGMA cache_size = 65536
f) Inserts are bundled into one transaction, sometimes as many as 800 at a shot 
before .Exec(COMMIT) is called.
g) No database error codes were generated.
h) There are no other programs running when our application is running and 
Windows Task Manager (processes and performance) shows no unusual activity. 

Description: Program runs, inserts between 500 and 800 records into the 
current-run db, and then at various points in reads/inserts (within 10 seconds 
after the first big insert) the 30-40 second hit will occur.

Important note: once that 30-40 second hit is done the program runs great-- for 
up to 12 hours in fact doing hundreds of thousands of transactions and with 
great speed. And it only stopped after 12 hours because we completed our tests.

We want to buy it but are concerned about the 30-40 second hit.

Anyone got an idea what might be going on?

Thanks much,

Tom Nicholas
http://www.thntech.com 


Reply via email to