No. I don?t mean [SQLite] will invoke the busy-handler.
I mean I can modify the source code here and let it invoke busy-handler in WAL.
Because it will not result in a deadlock in WAL.
So can I do this?
????
???:Dan Kennedydanielk1977 at gmail.com
???:sqlite-userssqlite-users at mailinglists.sqlite.org
????:2016?2?25?(??)?17:36
??:Re: [sqlite] Why skip invoking busy handlerwhilepBt-inTransaction!=TRANS_NONE
On 02/25/2016 09:53 AM, sanhua.zh wrote: So can this be understood as, if I
run my code in WAL, I can invoke busy handler even it in TRAN_READ? No. The
busy-handler is not invoked when trying to upgrade from a read to a write
transaction. Regardless of journal mode. Dan. ???? ???:Dan
Kennedydanielk1977 at gmail.com ???:sqlite-userssqlite-users at
mailinglists.sqlite.org ????:2016?2?24?(??)?23:52 ??:Re: [sqlite] Why skip
invoking busy handler whilepBt-inTransaction!=TRANS_NONE On 02/24/2016 08:32
PM, sanhua.zh wrote: In the source code of SQLite, btree.c,
sqlite3BtreeBeginTrans function, The code do { /* Call lockBtree() until either
pBt-pPage1 is populated or ** lockBtree() returns something other than
SQLITE_OK. lockBtree() ** may return SQLITE_OK but leave pBt-pPage1 set to 0 if
after ** reading page 1 it discovers that the page-size of the database ** file
is not pBt-pageSize. In this case lockBtree() will update ** pBt-pageSize to
the page-size of the file on disk. */ while( pBt-pPage1==0 SQLITE_OK==(rc =
lockBtree(pBt)) ); if( rc==SQLITE_OK wrflag ){ if( (pBt-btsFlags
BTS_READ_ONLY)!=0 ){ rc = SQLITE_READONLY; }else{ rc =
sqlite3PagerBegin(pBt-pPager,wrflag1,sqlite3TempInMemory(p-db)); if(
rc==SQLITE_OK ){ rc = newDatabase(pBt); } } } if( rc!=SQLITE_OK ){
unlockBtreeIfUnused(pBt); } }while( (rc0xFF)==SQLITE_BUSY
pBt-inTransaction==TRANS_NONE btreeInvokeBusyHandler(pBt) ); You can see
pBt-inTransaction==TRANS_NONE is one of the condition that invoke busy handler.
There is a simple way to simulate a situation that does not invoke busy
handler: 1. begin a transaction without ?IMMEDIATE? and ?EXCLUSIVE? 2. run a
read operation, like ?SELECT?. This will let pBt-inTransaction be TRANS_READ 3.
run a write operation, which will invoke sqlite3BtreeBeginTrans again. And if
it becomes SQLITE_BUSY, then btreeInvokeBusyHandler will be skiped and no retry
will happen. So it?s the question I confused. Why SQLite skip invoking busy
handler while it's in TRANS (either read or write) ? Assuming you're not using
wal-mode, it's because the two processes will be waiting for each other. The
transaction opened in step 1 cannot be committed until the read-only
transaction started in step 2 has ended. So if you did invoke the busy-handler
in step 3, the two processes would each be waiting for the other to give up.
Not much point to that. In wal-mode it's a little different. The transaction
opened in step 1 could be committed, but attempting to open the
write-transaction in step 3 following that would fail with
SQLITE_BUSY_SNAPSHOT. Dan. _______________________________________________
sqlite-users mailing list sqlite-users at mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________ sqlite-users mailing list
sqlite-users at mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________ sqlite-users mailing list
sqlite-users at mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________ sqlite-users mailing list
sqlite-users at mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
