On Jan 22, 2013, at 8:18 PM, Keith Medcalf <kmedc...@dessus.com> wrote:
> I presume that you are using some kind of input-driven or event driven > application which may get a request to process a query "in the middle" of > your update transaction. That is correct. > One of the advantages of WAL and using a separate reader and writer > connection is that the reader connection will not see "uncommitted" data from > the "writer". This is a good point and one I had not considered because I haven't been bit. In our application, the schema itself has kept us out of trouble, since the readers generally (always?) deal with a part of the schema uninvolved with the data collection. That is, they are looking up data to support the collection, but are not interested in the specific data being collected. Kind of. (It is a complicated program and I would not be surprised if there are some corner-cases to this statement.) It may be worth pursuing this approach anyway to make the most robust wrapper possible (and remove these concerns from the working set of things I have to worry about!). > One way you might do this is to modify your wrappers ... > keep a "usage" count Turns out the wrappers already have smart, reference counted objects for statement handles and the DB objects themselves, so hooking in the logic you suggest would be straightforward. > it may be better to think about such possibilities before they notice it and > claim your application is "broken" ... or even worse is acting "mysteriously" > in their eyes. > So, you've worked here too, eh? :-) Anyway, I think this is a powerful model and, given the wrappers, I think I can experiment with it in a low-risk way. I look forward to doing so. In other news, last night I coded the the "secret singleton handle" -- actually a cache keyed by DB filename -- works well, and it may be just me, but I feel like it sped up certain operations quite a bit. We'll see what the QA folks tell me later on today! Thanks again for all this. Very productive. -- Ward _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
