Re: [sqlite] Shared Cache unlock notification to multiple threads
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
[sqlite] Shared Cache unlock notification to multiple threads
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? I would naively propose to keep any unlock-notify callback registered, also if for the same connection. But would not wish to complicate things. It is a somewhat crazy case and may as well be dealt with in the application that wishes to support it. Thanks for this most interesting development, Edzard Pasma ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
