I agree. Applications shouldn't worry about locking and timeouts. That would be the job for the db core engine, returning as few (none ideally) busy status code as possible.
Also, it is not always possible to decide which thread is better to rollback since no info is provided about the status of what it is performing (commit, update, etc). ----- Original Message ----- From: "Rob Groves" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, September 01, 2004 12:34 AM Subject: RE: [sqlite] Locking in 3.0.5 > >>So, Rob, are you go to tell us if you think the change > >>is an improvement or not? > > It seems that with either of the new schemes, when using > sqlite3_busy_timeout() one thread is going to timeout sooner > or later. That being the case I prefer the new version on > efficiency grounds. > > Being a lazy programmer, I like the behaviour of 2.8.15 > where both threads can get to complete their update, timeouts > allowing. This is behaviour that I am also used to with > MS SQL Server. > > I agree with you that many programmers (myself included) > don't want to have to worry about this stuff too much > when using SQLite. > > Rob. >
