On 14.03.2011 17:13, Stefan Sperling wrote: > On Mon, Mar 14, 2011 at 05:05:39PM +0100, Stefan Sperling wrote: >> The concern seems to be that invoking a notification callback could >> attempt to modify DB state, correct? Which would deadlock if you invoke >> the callback after starting a transaction to tweak changelist information >> but before this transaction has been committed (i.e. the write lock has >> been released)? > Of course, the same problem happens when the notification callback > does a *read* operation on the DB (because writers block readers -- > somehow this restriction is kinda hard to getting used to...)
The restriction that you may not invoke a callback from within a sqlite transaction remains. That's what the temporary results tables are for -- they live outside transactions on the main wc-db. Still, wherever possible, we shouldn't allow wc-db modifications from within callbacks, except in a controlled manner through the wc-db API itself (e.g., modifications could also be queued to a temporary table whilst holding a read lock on wc-db; block writers, but lets other readers continue, and writers need exclusive locks to the WC anyway). -- Brane
