[EMAIL PROTECTED] wrote: > "Rob Menegon" <[EMAIL PROTECTED]> wrote: > >> Not sure whether I understand how this would occur. >> >> The application is not doing or responsible for the updates to the database. >> Its only function in life is to retrieve and display data. Updates, >> modifications occur via another application, so I was incorrect in my >> previous response to you - one user (app) doing updates and another >> displaying data - independent processes. >> >> > > Poll. Monitor the modification time on the database file and > when it changes, update your display. You can poll the modification > time of a file 10 times per second with no measurable CPU overhead. > > If you need to know specifically what changed, create triggers > that write a change log into a special table. > -- > D. Richard Hipp <[EMAIL PROTECTED]> > > Ick. Polling is evil. :) Granted, if your box can handle it, then fine. But consider that polling code will never get paged out, it will stay stuck in your processes' working set, and it will consume CPU cache entries for the code and data that it touches. You have to balance how often you expect a write event to occur with how often you are willing to have a read cycle that determines that nothing changed, ie, your "miss rate".
If both the reader and writer are running on the same host, then use some form of IPC. Windows has lots of IPC mechanisms. Unix has some SYS-V IPC, but I haven't used it in a while. You could also use a file handle (trap SIGIO) or socket to do IPC. (disclaimer: I'm not saying that the following is the "one true way", it is just an example of something that I did to solve the same problem as the original poster): Years ago I wrote a system with one reader and many writers. The writers would insert some entries into a DB2 table on an IBM zSeries mainframe. I wanted the reader to process these entires as soon as they were written, but I didn't want to poll every few seconds. btw, the writers and readers were not on the same host. So, I wrote a stored procedure for DB2 that sent a UDP packet to a socket on my reader box. I made this stored proc part of the insert trigger for the table. The reader process created a socket and added that socket to its main "select()" call. Whenever the table was inserted into my process knew about it in < 50 ms. In case I missed a UDP packet, or my process was not running when the table was updated, I did still poll the table. But only once every 30 or 60 seconds. The really cool thing is that my UDP packet contained the primary key of the row that was inserted. So the reader could go directly to it. The reader had reasonable security (what I considered reasonable for the problem domain and the network) UDP packets were only accepted if they came from the server. The WAN had firewalls to prevent source spoofing. I wanted to add some sort of "cryptographic signing", but never got around to it. Now in your case, sqlite is not a database server like DB2. But your could still have a trigger in sqlite that fires off a UDP packet, or sets some other IPC mechanism into action.
