Bill,
You have an interesting situation, and a general one since you have data
distributed across a network. I would be tempted to define a remote
procedure call using TCP/IP or whatever and use that to notify database
changes. Use a message passing approach.
BTW, in a new system you would do well not to use the deprecated
sqlite3_exec API call.
Bill Gatliff wrote:
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.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------