On Wed, Sep 29, 2010 at 3:20 PM, Erik Fears <[email protected]> wrote:
> sqlite-users, > > Here's my test environment: > > -RHEL 5 on a vmware server (trying to move this to ESX) > -C++ with 3 threads. One of them a write thread, one a main reader thread, > and one a diagnostic reader thread > -journal-mode=WAL > -no change to default synchronization mode > > The write thread is updating a fairly small (< 1k) blob on one table. I can > see the change on my diagnostic reader thread, but my main reader thread > appears to be acting on an old copy. It has no application side caching, so > would be doing a SELECT everytime it needs this data. It appears to have an > old copy of this data until I restart the daemon > My guess is that you are holding a transaction open on the reader thread. As long as you have a transaction open, the reader will continue to see the state of the database as it existed when the transaction was first started - no updates will be visible to that reader, though the updates will be visible to other readers who start their transactions after the update occurs. This is a (very deliberate and desirable) feature, not a bug. > > Are there known consistency/timing issues with WAL? I'm wondering if vmware > server's outdated disk support is causing any issues. > > More importantly, this is pretty hard to diagnose and catch. Are there any > sqlite side logging or diagnostics I can enable that will help me prove > where the bug lies (my code, sqlite, vm)? I have sqlite side logging > enabled. I've played around with sqlite3_trace, but that only appears to > log > queries and not results. > > Thanks! > --erik > _______________________________________________ > sqlite-users mailing list > [email protected] > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- D. Richard Hipp [email protected] _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
