On 10/31/07, Bill Gatliff <[EMAIL PROTECTED]> wrote: > Trevor Talbot wrote:
> > If your platform has a file modification notification mechanism, you > > may be able to sleep on that instead. Of course the problem with this > > approach is that it's only a coarse-grained "something changed" > > notification, and doesn't tell you what changed. You may be able to > > counter that by having the trigger store a note about what changed in > > a separate table that your GUI queries when it wants to know > > specifics. > Perhaps, but that may just move the problem. The "GUI information" > table might not be committed before the GUI process wakes up to find out > what happened. If it's created in a trigger, it will be part of the same transaction as the updated data. The database file won't be modified until commit time. Depending on the platform, it may fire the notification before the commit has finished writing data, but since sqlite holds an exclusive lock on the file during that time, the GUI process will see SQLITE_BUSY and can simply sleep a short time and retry. You'd have to handle that case anyway, as another writer might start committing before the GUI process has a chance to respond to the previous notification. > > If you don't have a cheap file notification, something more creative > > might be necessary. Do you control the sqlite library used by the > > data writers? Perhaps you can modify it to provide notifications > > immediately after commit instead. (I'm assuming you don't want to > > modify the writers themselves directly, by having them signal after > > they issue a COMMIT.) > I control the code on both ends. I looked at the sqlite3 code, and the > places to modify didn't exactly jump off the page at me. :) > What about sqlite3_commit_hook()? Though the (very few) examples I've > managed to find don't make it clear how to figure out the rowid that was > updated. And without that, I can't easily determine which semaphore I > need to post to... Can I pass the database handle as the argument to > the callback? It's a pre-commit hook, so it has the same problem as the triggers. I haven't tried modifying the code to add a post-commit hook, but sqlite3_commit_hook() is actually a good place to start: in main.c it sets db->xCommitCallback, which is called by vdbeCommit() in vdbeaux.c. It looks like you could add a call at the end of that function, after testing needXcommit. You'll still want the triggers to note what specific data changed, but you could simply have them store some state in a global variable that your new post-commit function checks to decide what semaphore to post to. ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
