Bill Gatliff wrote:
Guys:
I'm a relatively-new SQLite user, but I'm luuuvin' it! :)
My application is a mobile platform with a GUI that wants to display
frequently-updated data in a database. The GUI is a separate process
from the one providing the data, and is one of several consumers of that
data.
I prefer not to poll for changes, because the system is
performance-constrained. So instead, I'm using an AFTER UPDATE trigger
in the data-generating process to launch a C function that posts to a
semaphore. The GUI process is thus unblocked, and it then does a SELECT
to get the data. I'm using the C/C++ API everywhere.
The problem I'm seeing is that the GUI process is getting stale data in
its SELECT, unless it does a brief sleep between the sem_wait() and the
sqlite3_exec(). Specifically, the value returned is the value
immediately before the UPDATE. It's as if the trigger in the
data-generating process and the query in the GUI process are both
running before the new value is actually committed to the database file
and/or whatever caches are in between.
Is this expected behavior? Is there a better workaround than simply
sleeping after getting unblocked? Am I missing an entirely different---
and better--- way of synchronizing my GUI to the database?
Thanks!
b.g.
Perhaps your application sjould post its signal after the COMMIT has
executed. A pause to give time for the COMMIT is a fragile approach.
Can you use a message queuue to send the updated data to the companion
process?
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
