> Assuming I don't do any manual commits, what does sqlite do with the > data that has yet to be committed?
If you don't do commits (and "begins") of transactions by yourself then SQLite does that automatically after each executed statement. So when sqlite3_step returns you can be sure that everything is committed and everything is on disk. SQLite doesn't do any write-through caching. And as your transactions are small in volume then journal size is also always small. > Unfortunately I don't have access > to memory leak detection tools, otherwise that would obviously be > ideal. Again, try to call sqlite3_memory_used() several times during work of your application. What does it say to you? Pavel On Wed, Jul 22, 2009 at 2:30 PM, Zachary Turner<divisorthe...@gmail.com> wrote: > On Wed, Jul 22, 2009 at 10:47 AM, Pavel Ivanov<paiva...@gmail.com> wrote: >> SQLite synchronizes with disk during every commit (either issued by >> yourself or automatic) at least 2 times (I don't know exact number). >> So it's quite natural that it spends most of the time in winSync(). >> But I still didn't understand from your explanation how exactly your >> application works and whether it's SQLite uses memory or your >> application does. >> BTW, how do you measure memory usage and how do you see leakage? What >> does sqlite3_memory_used() returns for you? >> >> Pavel > > I was measuring memory usage by just looking at windows task manager. > If I watch it for about 20 seconds, it goes up indefinitely until I > stop reading more data from the file (and thus stop issuing insert > statements), at which point it steadly declines for a while. > > Assuming I don't do any manual commits, what does sqlite do with the > data that has yet to be committed? I thought it would store it in the > journal file, but the journal file always remains consistently very > small (around 8K max), and data gets written to the actual database > file even when I'm not doing commits. > > I have some ideas about the memory consumption problem that turns out > to be related to my own code (I agree it's amazingly complicated, but > it has to be for reasons outside of what we're doing with sqlite). I > will investigate that further and post back if I am able to pinpoint > the issue to sqlite more closely. Unfortunately I don't have access > to memory leak detection tools, otherwise that would obviously be > ideal. > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
