> 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.
Don't fool yourself. There's no value of timeout that will guarantee fairness. Just consider this scenario: process #1 - BUSY, sleep 10 process #2 - (after 5ms) not BUSY, getting lock, return Or this: process #1 - BUSY, sleep 10 process #2 - (after 5ms) BUSY, sleep 10 process #1 - (after 5ms) still BUSY, sleep 10 process #2 - (after 5ms) not BUSY, getting lock, return process #3 - not BUSY, getting lock process #1 - still BUSY, sleep 10 process #3 - releasing lock, return ... I don't believe these situations are somewhat fairer than progressive timeouts. For me they work identically. But I'm not very strong in probability theory, so anyone wanting to prove one point or another is welcome. @Sam: You might want to look at sqlite3_busy_timeout function - it will setup all waiting while database is BUSY for you, so you don't need to write any additional code. Pavel On Tue, May 18, 2010 at 11:19 AM, Black, Michael (IS) <michael.bla...@ngc.com> wrote: > 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 > > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
