Re: [sqlite] Question on errors - IOERR and CANTOPEN

[Dennis Volodomanov]

Hi Filip,

> what SQLite version and on what platform are you using? There was a
> bug in SQLite 3.6.13 on Windows where SQLITE_CANTOPEN was incorrectly
> returned during journal check when race condition between two threads
> was hit. Also there could be some other software interfering with the
> journal deletion, which could cause SQLITE_IOERR. Typically
> TortoiseSVN has the habbit of doing this. While there is mechanism in
> SQLite to workaround this, it's far from prefect. Known workaround is
> to use "pragma journal_mode=persist;". If this solves your problems,
> then you most probably hit this bug.

I'm using 3.6.14.2 on Windows (compiled in from the amalgamation). I do
have several processes (2 actually, one is an application and the other
is a service) trying to open the same database file. Whoever opens it
first, gets rights to read/write to it (to do this, I'm using a BEGIN
IMMEDIATE TRANSACTION in a loop). When that program exits, the other has
a chance to take over and carry on. This BEGIN sometimes causes the
errors above.

At the moment, I'm just sleeping and retrying and things seem to be ok,
but I'm not confident that it's the right approach.

I'll try the pragma you mention and see if it happens again.

Thanks!

   Dennis


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Question on errors - IOERR and CANTOPEN

[Filip Navara]

Hi Dennis,

what SQLite version and on what platform are you using? There was a
bug in SQLite 3.6.13 on Windows where SQLITE_CANTOPEN was incorrectly
returned during journal check when race condition between two threads
was hit. Also there could be some other software interfering with the
journal deletion, which could cause SQLITE_IOERR. Typically
TortoiseSVN has the habbit of doing this. While there is mechanism in
SQLite to workaround this, it's far from prefect. Known workaround is
to use "pragma journal_mode=persist;". If this solves your problems,
then you most probably hit this bug.

BTW, I don't know how many people are affected by this journal
creation bug, but there's a reliable way to workaround it. The
solution would be to detect the "delete pending" state and rename the
journal file in that case. This will allow the new journal file to be
created and the old one will disappear as soon as the offending
application closes the last handle to it. Anyway... don't want to hick
your thread :)

Best regards,
Filip Navara

On Tue, May 26, 2009 at 7:51 AM, Dennis Volodomanov
 wrote:
> I sometimes get either a SQLITE_IOERR or a SQLITE_CANTOPEN when issuing
> BEGIN IMMEDIATE TRANSACTION or END TRANSACTION, however the database
> file is there and is being used by another thread. I thought I'd get the
> usual SQLITE_BUSY or SQLITE_LOCKED, but sometimes these file-related
> errors come up.
>
>
>
> Does anyone know why they come up and what should be the correct logic
> to continue? Should (and can it) the operation in question be retried,
> as if a BUSY/LOCKED was encountered?
>
>
>
> Thanks in advance,
>
>
>
>   Dennis
>
>
>
> ___
> 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] Question on errors - IOERR and CANTOPEN

[Dennis Volodomanov]

I sometimes get either a SQLITE_IOERR or a SQLITE_CANTOPEN when issuing
BEGIN IMMEDIATE TRANSACTION or END TRANSACTION, however the database
file is there and is being used by another thread. I thought I'd get the
usual SQLITE_BUSY or SQLITE_LOCKED, but sometimes these file-related
errors come up.

 

Does anyone know why they come up and what should be the correct logic
to continue? Should (and can it) the operation in question be retried,
as if a BUSY/LOCKED was encountered?

 

Thanks in advance,

 

   Dennis

 

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users