On 3/8/06, Ludovic Ferrandis <[EMAIL PROTECTED]> wrote: > > The only issue that remain for instance, is how to manage the SQLITE_LOCKED > error. It's not very clear in the documentation when this error could be > returned (instead of SQLITE_BUSY).
LOCKs happen when a process has the file locked for writing. Lock management is generally difficult to do well with a simplistic wrapper. A wrapper doesn't know how the code calling it is using the database. If you are reading static setup data from configuration table you might be sure that this data will never change during execution. Therefore "dirty read", with no locking may be what you want. In other cases you definitely don't want this. I set mine up to retry the update when a lock error happens. I do it in a loop with a varying delay between retries. With my application the assumption is that all other processes accessing the data are cooperative and any writes will be done quickly and the lock released. If it takes too long I return a failure message to the operator and give them the option to retry the command again if desired.
