On Mar 23, 2009, at 5:45 AM, Edzard Pasma wrote: > Hello, > > The new sqlite3_unlock_notify API, described in > http://www.sqlite.org/draft/c3ref/unlock_notify.html > and expected in SQLite 3.6.12, may have a restriction for use when > multiple threads share the same connection. The documents states: > > """ There may be at most one unlock-notify callback registered by a > blocked connection. If sqlite3_unlock_notify() is called when the > blocked connection already has a registered unlock-notify callback, > then the new callback replaces the old. """ > > I expect the following goes wrong then: > > Connection A: UPDATE t1 SET .. > > Connection B, thread 1: SELECT * FROM t1 --> database table locked > > Connection B, thread 2: SELECT * FROM t1 --> database table locked > > If both threads register to be notified, only one will get called > when the lock is cleared. The other is forgotten?
The sqlite3_unlock_notify() interface assumes that each thread has its own connection. Violate this assumption at your peril. D. Richard Hipp d...@hwaci.com _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
