Interesting...but that logic means that later processes might get their results before earlier ones. Imagine this: process #1 hits BUSY -- sleep 9,10,11,12,13,14,15 Shortly after the sleep 15 process#2 comes in process #2 hits BUSY -- sleep 9 -- gets lock - returns (note process#1 is still sleeping) You'll get fairer resolution of busy contention with a fixed timeout. Just do 10ms 50 times. That way the first guy in should get the first results. Michael D. Black Senior Scientist Northrop Grumman Mission Systems
________________________________ From: sqlite-users-boun...@sqlite.org on behalf of Sam Carleton Sent: Tue 5/18/2010 9:57 AM To: General Discussion of SQLite Database Subject: Re: [sqlite] read only databases and in-memory databases On Tue, May 18, 2010 at 7:35 AM, Black, Michael (IS) <michael.bla...@ngc.com > wrote: > I think I see a potential problem with your logic. You say "up to 2 > seconds" and "up to 4 times". So it sounds like you're doing a 500ms sleep > on your retry with 4 tries? > Actually no, not just 4 retries. What I did was use some logic in the busy handler to start with a small sleep and increase the sleep with each call into the handler, after about 500 milliseconds it bails and then the whole connection is closed and this is tried again. What I am doing basically is this: 1 + 2 + 3 + 4 ... n, so on the 2 try it is 3 millisecondes, on the 10 try it is 55 millseconds, once the total gets to about 500 milliseconds, it bailes. I believe I actually start where n is 9 and goes until n is 18. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
