On Fri, Nov 8, 2013 at 2:58 PM, Xinhuan Zheng <xzh...@christianbook.com>wrote:
> The query is from the application code not the 'select 1' test query. > OK, then it seems like Apache::DBI may not have a problem. > While most of time I saw Apache::DBI->connect is called but sometime from > a process, it will print out it finds a cached connection and ping is ok > but sometimes from the same process it didn't find a cached connection. > Since it's the same process, it doesn't make sense it can find a cached one > then it didn't find any. Even after it says it didn't find a cached one > then after that it prints out it still has a cached one and can use that > one. It sounds like in same process sometimes the Apache:DBI connection > cache can be accessed but sometimes it cannot. > The cache can always be accessed. It's just a hash in a global variable. There are a couple of possible explanations for what you're seeing, off the top of my head. One is that you might be sending in slightly different connection parameters, which means you can't use the cached connection. Another is that your code might not be calling DBI->connect() or DBI->connect_cached(). > The base class is similar to a class in Java world. Basically it has set > and get methods. Among other things, it sets $db and gets $db. The class > has its own fetch method and it'll use $self->db method call to do the > fetch/insert,etc. > It's ok to keep a database handle during the length of one request, but you shouldn't keep it in your own global between requests, so if objects of this class stay around for longer than one request you should not store a db handle in them. The safest thing would be for your $self->db() method to just call DBI->connect_cached() every time. > BTW, the class has a method AUTOLOAD, although I don't quite understand > how AUTOLOAD works. > There's a lot of good documentation on AUTOLOAD in the Perl man pages and books. It's not relevant to your database issues though. - Perrin
