On Mar 25, 2017, at 5:52 PM, petern <peter.nichvolo...@gmail.com> wrote:
> So finally, here is the question. Is there a SQLite API way for reader > connections to block and wait for a meaningful change, like a new row, in > the 'cmd' table instead of madly polling and using up database concurrency > resources? [Block with timeout would be even more desirable of course.] No, there is not. As others have pointed out, this is not a very “databasey” thing. The whole point of relational, ACID transaction databases is that they provide an atomic “snapshot in time” view of a data set. They do everything they can hide changes within a transaction, and there is no way to issue a SELECT outside of a transaction. It sounds like you really need a message queue of some type, more of a pub/sub infrastructure. There are dozens of products out there that do this. That said, if all the processes are on a single system (as they would have to be to be using SQLite to communicate) it might make a lot more sense to use a simple text file. One writer (or more) can append lines, and multiple processes can read from the end, using blocking I/O on the file, not unlike a “tail -f” in the UNIX world. If you keep track of which line number you’re on, you can retry or re-pickup if a reader process needs to restart, plus the file provides a log of all messages. Simple, easy, and straight forward. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable." -- Angela Johnson _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
