On 21 Jul 2010, at 2:30pm, Sam Carleton wrote: > My issue with only attaching to the EventDB for only as long as a command is > trying to use it is: The EventDB is used a LOT, a WHOLE lot. If I attach > and drop between each little call, then within one HTTP request I might > attach and drop 3 to 8 times. What is the cost associated with > attaching/dropping a database? Since it involves attaching to a physical > file, I am assuming it is a bit high. > > As far as telling my application when the EventDB file is out of date: It > would be pretty easy for me to add a timestamp to the EventDB variable that > is in the primary database, but... Once I get a connection from the > connection pool, how do I know the age of that connection to know if the > EventDB it is attached to is the new one or the old one? Is there some > connection age or timestamp I could use? I am guessing not, which is why I > am using the PRAGMA database_list to determine if the EventDB is attached > and if so, find the physical path to the EventDB file to see if it matches > with the current system settings.
Ah. If all you are doing is replying to one HTTP request then that'll take less than one second, right ? You don't have to worry about the 'right' EventsDB file changing during a request because it doesn't last long enough. Your users will have no way of telling if their data is almost one entire second out of date. So you don't need a complicated semaphore method to communicate with existing processes, all you need is a way to tell a new process which events database file to attach. As you note, this can be done various ways: put another text file on the server called 'currentevents.txt' and in that file put the full path of the current event.sqlite file. Or you could use an 'include' file for your PHP code, or whatever language you're using for your web backend, and write software to rewrite that 'include' file. Or you could store the path as something that can be looked up in another SQLite database, though that would be a little more 'expensive'. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
