Hi,

Got it. I did read this, but probably did not understand very well.
Yes, it makes sense why busy handler is not called. May be it is a good idea to 
site some examples in the documentation...

Regards,
 
Prakash Bande
Altair Engg. Inc. 
Troy MI
Ph: 248-614-2400 ext 489
Cell: 248-404-0292
-----Original Message-----
From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] 
On Behalf Of Jay A. Kreibich
Sent: Friday, November 12, 2010 7:16 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Busy handler not called

On Fri, Nov 12, 2010 at 04:51:11PM -0500, Prakash Reddy Bande scratched on the 
wall:
> Hi,
> 
> I have set a busy handler.
> 
> int ret = sqlite3_open(dbname.c_str(), &m_ppDb);
> sqlite3_busy_handler(m_ppDb, &hwLMsqlite3BusyHandler, 0);
> 
> However it is not getting called.

  As the docs for sqlite3_busy_handler() point out, this is exactly how
  it is expected to work:

  <http://www.sqlite.org/c3ref/busy_handler.html>

      The presence of a busy handler does not guarantee that it will be
      invoked when there is lock contention. If SQLite determines that
      invoking the busy handler could result in a deadlock, it will go
      ahead and return SQLITE_BUSY or SQLITE_IOERR_BLOCKED instead of
      invoking the busy handler. Consider a scenario where one process
      is holding a read lock that it is trying to promote to a reserved
      lock and a second process is holding a reserved lock that it is
      trying to promote to an exclusive lock. The first process cannot
      proceed because it is blocked by the second and the second
      process cannot proceed because it is blocked by the first. If
      both processes invoke the busy handlers, neither will make any
      progress. Therefore, SQLite returns SQLITE_BUSY for the first
      process, hoping that this will induce the first process to
      release its read lock and allow the second process to proceed.



> 1. Using the sqlite3.exe run the following commands
> begin transaction;
> update users set name="hello"
> 
> 2. Note I have not yet commited.

  This will grab the reserved lock, and knows it will want to get an
  exclusive to finish the transaction.

> From my program I call
> 
> int ret = sqlite3_exec(m_ppDb, query.c_str(), &hwLMsqlite3TableCallback, &rs, 
> &zErr);
> 
> I get SQLITE_BUSY and hwLMsqlite3BusyHandler is not getting called.

  You said this is another update, so same thing... Any attempt to
  promote to a reserved lock will sense a possible deadlock and
  skip the busy handler.  At this point, there is no way out of
  this situation other than having the second query rollback.
  Exec is likely to do this automatically, aborting the second
  UPDATE, and returning the original SQLITE_BUSY error.


    -j

-- 
Jay A. Kreibich < J A Y  @  K R E I B I.C H >

"Intelligence is like underwear: it is important that you have it,
 but showing it to the wrong people has the tendency to make them
 feel uncomfortable." -- Angela Johnson
_______________________________________________
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

Reply via email to