apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Garrett Rooney" <roo...@electricjellyfish.net>
Subject Re: SQLite3 BUSY return status
Date Mon, 17 Apr 2006 18:35:59 GMT
On 4/16/06, Bojan Smojver <bojan@rexursive.com> wrote:
> In this part of the code of the SQLite3 driver (function
> dbd_sqlite3_select):
>
> -----------------------------------------
> if (ret == SQLITE_BUSY) {
>     if (retry_count++ > MAX_RETRY_COUNT) {
>         ret = SQLITE_ERROR;
> } else {
>     apr_dbd_mutex_unlock();
>     apr_sleep(MAX_RETRY_SLEEP);
>     apr_dbd_mutex_lock();
> }
> -----------------------------------------
>
> We are returning SQLITE_ERROR when maximum number of retries has been
> exhausted. However, the caller may want to know that there was no error,
> but a timeout instead, therefore potentially retrying the operation from
> the calling code (in fact, for high concurrency of requests, SQLITE3 is
> very likely to give us this kind of behaviour). Maybe we should return
> APR_TIMEUP or APR_EBUSY instead?

+1, either of those would seen fine to me.

> PS. I think returning native SQLITE3 or other database codes isn't very
> useful anyway - the caller most likely won't have access to code
> meanings (i.e. headers files) of native databases. I think we should be
> returning APR error codes throughout DBD.

That would make sense to me.

-garrett

Mime
View raw message