Thanks for all the sage observations. As a server with a connection pool, I'm avoiding some of issues brought up. Every thread has their own connection handle and when done, it goes back into the pool so no sharing. I spent some hours reading everything I could find about this product and concurrency issues and my goal is ultimately to avoid busy's and lockout's. This library is quite fast and performance isn't going to be an issue. After I put the backup api in the server code base, I'll hit it with several thousand threads, mixed reads and writes, as fast as I can create them both with the backup api active and without and see what the session log records.
Rick Kelly -- View this message in context: http://sqlite.1065341.n5.nabble.com/Client-Server-Best-Practices-tp79728p79920.html Sent from the SQLite mailing list archive at Nabble.com. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
