On Wed, Jul 21, 2010 at 11:23 AM, Simon Slavin <slav...@bigfraud.org> wrote:
> > On 21 Jul 2010, at 3:53pm, Sam Carleton wrote: > > > In the end, I am looking for the best way to determine if the connection > > contains the correct EventDB, since a connection can live for a LONG LONG > > time. > > Sorry, I misunderstood. I thought that your process lasted only long > enough to answer one HTTP query. > > > Right now I am using PRAGMA database_list to get the list, find if there > is > > an EventDB and if so, is it the correct one, each and every time the > system > > gets a connection from the pool. This could happen between 3 to 8 times > in > > one request. > > Could you keep, for each connection, its own independent variable with the > currently connected EventDB path in ? Since only this routine establishes a > connection nothing can change it behind its back. Keeping the information > in your own variable will be much 'cheaper' than having to execute an SQLite > command and parse the result every time. > > In other words, "I am connection number 2. I am new and I have no been > ATTACHed to any EventDB." or "I am connection number 2. I have been > ATTACHed to EventDB X." > Well, since DBD is part of the Apache Foundation, I can hack the code all I like, though I would prefer not. By default my code knows nothing about a connection other than it is a connection to the database. > > The question is: Is it worth my time to hook into the whole request > process > > before any other part of my modules run and do this check only once, so > the > > rest of the code that gets the same connection 3 to 8 times can skipt the > > check, or is the cost of this check so small that it is not worth my time > to > > optimize? > > Since all 3 (or 8) calls to service a single HTTP request happen within a > short time, I suspect that for each HTTP request it's only worth checking > only once. > I could not agree more then it will be more efficient of the code to only do the check once. But I must factor in the efficiency of my time as a developer and the efficiency of code maintenance, as well. For a time perspective, what I have is working well, if the execution cost is low, let it do it 3 to 8 times and I can refocus on what my customers really care about, the business logic. If it is a really expensive, then I have to identify the correct hook to get that will guarantee me that it will be called before anything else in the request, but not called too early that connections cannot be had, I have to implement the hook. And the biggest thing is maintenance, if I start relying on this hook to be before anything else, I need to make sure that it stays that way in the future. Right now I don't have any early hooking stuff, but that might change in the future, one never knows. What a headache to chase down if another hook is put in front of this one because the knowledge was lost on the exact details of why this hook happened when and where it happens. So from my time and long term maintenance, what I have now is the 'cheapest' solution. But the question is, how big of a performance price will I pay for this 'cheap' solution? I know my code is really short and fast and as far as I am concerned a zero on the cost scale, especially on modern machines. I am wondering how much work there is to actually preform the PRAGMA database_list, is that speedy fast because it is all in memory, or is there some actual disk IO that needs to happen to return the result set? If it is all in memory, I am guessing that it, like my code has a cost close to zero, if it has to hit a file, then I don't know and I am hoping someone with a better understanding of how SQLite works might know. Sam _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
