Re: [sqlite] WAL for production use
I did see some persistent database locks in WAL mode in SQLite 3.7.4 and previous versions (I don't test 3.7.5 yet ) and all queries are failed with message about database locked by write query. So we need vacuum database, try change to "delete" mode and vacuum again... In "delete" mode these applications work fine a lot of time. But I can't write tests for reproducing the problem. My hosts are using 32bit and 64bit debian linux (squeeze) with ext3 filesystem. So WAL may be dangerous for some projects now. 2011/2/3 Dustin Sallings > > On Feb 2, 2011, at 8:14, Duquette, William H (318K) wrote: > > > In SQLite 3.7.4/3.7.5, does WAL seem to be stable enough for production > use? > > > I'm using it very, very heavily right now. > > -- > dustin sallings > > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- Best regards, Alexey Pechnikov. http://pechnikov.tel/ ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] WAL for production use
On Feb 2, 2011, at 8:14, Duquette, William H (318K) wrote: > In SQLite 3.7.4/3.7.5, does WAL seem to be stable enough for production use? I'm using it very, very heavily right now. -- dustin sallings ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] WAL for production use
Thanks, Richard! Will On 2/2/11 8:22 AM, "Richard Hipp" wrote: On Wed, Feb 2, 2011 at 11:14 AM, Duquette, William H (318K) < william.h.duque...@jpl.nasa.gov> wrote: > Howdy! > > In SQLite 3.7.4/3.7.5, does WAL seem to be stable enough for production > use? > Mass-market consumer products are shipping with WAL now, I am told. > > And then, an architecture question. I have an app that occasionally needs > to do significant background processing. I'd like to keep the GUI awake and > looking at the current data set while the app is computing the updated data > in the background. The obvious notion is to ask a secondary process or > thread to do the background processing. However, both the background task > and the GUI need to access the same DB. > Please use a background process, not a thread :-) > > WAL seems perfectly suited to this architecture. While the background > processing is going on, only the background task can write to it; but the > GUI can read the database all it likes, seeing only the data committed > before the background task started its current transaction. > WAL does exactly what you want, Will. As long as you only have a single writer, it will work great. > > Does this make sense? Is there an easier way to do it that doesn't involve > WAL? > > Thanks very much! > > Will > > -- > Will Duquette -- william.h.duque...@jpl.nasa.gov > Athena Development Lead -- Jet Propulsion Laboratory > "It's amazing what you can do with the right tools." > > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- Will Duquette -- william.h.duque...@jpl.nasa.gov Athena Development Lead -- Jet Propulsion Laboratory "It's amazing what you can do with the right tools." ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] WAL for production use
On Wed, Feb 2, 2011 at 11:14 AM, Duquette, William H (318K) < william.h.duque...@jpl.nasa.gov> wrote: > Howdy! > > In SQLite 3.7.4/3.7.5, does WAL seem to be stable enough for production > use? > Mass-market consumer products are shipping with WAL now, I am told. > > And then, an architecture question. I have an app that occasionally needs > to do significant background processing. I'd like to keep the GUI awake and > looking at the current data set while the app is computing the updated data > in the background. The obvious notion is to ask a secondary process or > thread to do the background processing. However, both the background task > and the GUI need to access the same DB. > Please use a background process, not a thread :-) > > WAL seems perfectly suited to this architecture. While the background > processing is going on, only the background task can write to it; but the > GUI can read the database all it likes, seeing only the data committed > before the background task started its current transaction. > WAL does exactly what you want, Will. As long as you only have a single writer, it will work great. > > Does this make sense? Is there an easier way to do it that doesn't involve > WAL? > > Thanks very much! > > Will > > -- > Will Duquette -- william.h.duque...@jpl.nasa.gov > Athena Development Lead -- Jet Propulsion Laboratory > "It's amazing what you can do with the right tools." > > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] WAL for production use
Howdy! In SQLite 3.7.4/3.7.5, does WAL seem to be stable enough for production use? And then, an architecture question. I have an app that occasionally needs to do significant background processing. I'd like to keep the GUI awake and looking at the current data set while the app is computing the updated data in the background. The obvious notion is to ask a secondary process or thread to do the background processing. However, both the background task and the GUI need to access the same DB. WAL seems perfectly suited to this architecture. While the background processing is going on, only the background task can write to it; but the GUI can read the database all it likes, seeing only the data committed before the background task started its current transaction. Does this make sense? Is there an easier way to do it that doesn't involve WAL? Thanks very much! Will -- Will Duquette -- william.h.duque...@jpl.nasa.gov Athena Development Lead -- Jet Propulsion Laboratory "It's amazing what you can do with the right tools." ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
