On Thu, Nov 20, 2008 at 7:35 PM, Ron Peterson <[EMAIL PROTECTED]> wrote: > 2008-11-20_11:24:52-0500 Dick Davies <[EMAIL PROTECTED]>:
>> In a nutshell, the JPA config seems to assume that CURRENT_TIMESTAMP >> is low precision (i.e. hundredths of a second). > >> I've filed this as https://issues.apache.org/roller/browse/ROL-1760 , > I'll bet a bagel it's the same as this. > https://issues.apache.org/roller/browse/ROL-1657 > > I've been scratching my head about this myself the last couple of days. > Thanks a _lot_ for the diagnosis. No problem, I'm a PostgreSQL fanboy myself so if we can fix it for both I'll be very happy :) You can probably check if you like by turning off all but one of the scheduled tasks and then whacking up the debug level for JPA; try adding this to roller-custom.properties (we also took the server out of load balance so the only DB activity in the log was task related) tasks.enabled=PingQueueTask log4j.appender.roller.File=${catalina.base}/logs/roller-debug.log log4j.category.org.apache.roller.weblogger.business.runnable=DEBUG # generate an insane amount of JPA debugging openjpa.Log=commons log4j.category.openjpa.Tool=DEBUG log4j.category.openjpa.Runtime=DEBUG log4j.category.openjpa.Remote=DEBUG log4j.category.openjpa.DataCache=DEBUG log4j.category.openjpa.MetaData=DEBUG log4j.category.openjpa.Enhance=DEBUG log4j.category.openjpa.Query=DEBUG log4j.category.openjpa.jdbc.SQL=DEBUG log4j.category.openjpa.jdbc.JDBC=DEBUG log4j.category.openjpa.jdbc.Schema=DEBUG that's how we got the prepared statements that were being generated, then it's a case of grepping the source tree. To clarify; we don't have a fix for this yet, we've tried altering timestamp columns so they are less fine grained but I'm not convinced that will fix things. May resort to hacking the code today (to take out the extra WHERE clauses), will let you all know how that goes. Though if Dave wants to fix this and release 4.0.1 this afternoon, that'll be fine too :)
