John Stanton wrote:
Perhaps your application sjould post its signal after the COMMIT has executed. A pause to give time for the COMMIT is a fragile approach.
It is indeed! And just for the record, it's an approach that deserves absolutely no consideration by any system you want to depend on. I wasn't ever considering it, in fact. Just so I'm clear on that. You know, for the lawyers out there. :)
In my application, I have a lot of databases and tables, but the file holding the data of interest to the GUI has other data in it as well, so waking up on file change e.g. select(2) or poll(2) will cause the GUI process to wake up far more often than it needs to.
Combining a semaphore-in-trigger with a select() by the companion process doesn't work either, it turns out. Think about high system loads, where the wakeup from the semaphore posting is delayed until after the commit for that update has happened. Then a subsequent select() will sleep until somebody else touches the database, which might not happen for a while. Combine that with the fact that a select() might release because some non-GUI data was committed just before the GUI data--- but after the semaphore posting and wakeup, and I can't come up logic that doesn't get confused when things start to look like real-life.
The solution seems to be to not use an AFTER UPDATE trigger to post to a semaphore used as a notifier for any other context. Period. (I think that with sqlite3_enable_shared_cache(), you could still use semaphore-in-trigger notifications for same-context connections, but I haven't tested this). I can live with this, it's a minor code change.
And finally, the answer to the obvious question. There are several data generators in this system, and none of them has any awareness of the GUI. In fact, some embodiments of this system don't even have a GUI, and in others, the GUI lies across a LAN. So simply moving all the GUI-interesting data into its own database really isn't an option, though it would otherwise be the ideal solution because then I _could_ use select(2) et al. Right now, though, the schemas are designed to meet the needs of the system as a whole; the GUI has to take what's left. :)
b.g. -- Bill Gatliff [EMAIL PROTECTED] ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
