in reply to Mysql query cache and DBI

There's a DBI database handle attribute called "RowCacheSize", which can be set to "1" to "disable the local row cache" when calling connect(); I'm not familiar with Jnms::Database::Control::DatabaseManager, but if that is where the connect call is being made, that's where you'd want to check whether this parameter is being handled, and how you can control it.

(I don't know if this will solve your problem, but it looks like a good thing to try. I'm guessing the default is "0", which will "Automatically determine a reasonable cache size for each SELECT".)

UPDATE: The section in the DBI man page about RowCacheSize closes with:

See also the "RowsInCache" statement handle attribute.

There may be some situations where you want to control caching at the statement-handle level rather than the connection level. Having a row cache is usually a Good Thing, and disabling it indiscriminately might be a Bad Thing.

(Oops! Another update: I just noticed that "RowsInCache" is "readonly". Oh well, no cache control at the statement level. Good luck...)

Replies are listed 'Best First'.
Re^2: Mysql query cache and DBI
by josh803316 (Beadle) on Nov 07, 2009 at 19:44 UTC
    So I tried setting the RowCacheSize => 1 to no avail, I'm still faced with the same issue. I'm not sure what step to take next.....
    $dbh = DBI->connect($database,$self->{user},$self->{pass},{ RowCacheSi +ze => 1}) or die DBI::errstr; $dbh->{AutoCommit} = 0; $dbh->{RaiseError} = 1;
      It turns out the problem is related to transactions and AutoCommit......I had to do a $dbh->commit; after my reads (selects) in order to update the transactions. Once I added the commit after the select for my list_all it fixed the issue.
        Ah. That's good to know. And of course, now that it's clear that RowCacheSize had nothing to do with the problem, you probably want to set it back to the default behavior.
        Been banging my head against the wall for the last 24 hours, unable to find out why the heck Thread#2 wouldn't fetch whatever Thread#1 was inserting, even though I could fetch it from CLI or whatever, until I stumbled upon this post...