I'd like to turn these down, at least for now, as SQLite doc clearly
states as follows:

The ROLLBACK will fail with an error code SQLITE_BUSY if there are any
pending queries. Both read-only and read/write queries will cause a
ROLLBACK to fail. A ROLLBACK must fail if there are pending read
operations (unlike COMMIT which can succeed) because bad things will
happen if the in-memory image of the database is changed out from
under an active query.

And DBI doc also says

When all the data has been fetched from a "SELECT" statement, the
driver will automatically call "finish" for you. So you should *not*
call it explicitly *except* when you know that you've not fetched all
the data from a statement handle *and* the handle won't be destroyed

This rolling-back an unfinished query is obviously one of such
exceptional cases.

These patches also have side effects that probably surprise users. I
think it's better for you to add $sth->finish explicitly before you
call $sth->rollback for a reading query.



2011/10/15 Yuriy Kaminskiy <yumkam@mail.ru>:
In sqlite, ROLLBACK fails with SQLITE_BUSY when there are active/unfinished
SELECT statements.
As DBI's $dbh->rollback cannot handle errors in sane way, add workaround to
reset all sth and retry when $dbh->rollback fails with SQLITE_BUSY.

PS For whatever reasons, "Error handling, part 2" cannot be sent to list
(disappear into /dev/null without any diagnostics) :-|
Will retry in few days if it won't appear in gmane or list archives.

DBD-SQLite mailing list

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 3 of 4 | next ›
Discussion Overview
groupdbd-sqlite @
postedOct 14, '11 at 8:48p
activeMar 27, '12 at 3:53p



site design / logo © 2021 Grokbase