Row not found message in trace.db file

[Mark Addleman]

I get a number of "row not found when trying to delete from index" messages in the trace db file.  My JDBC url contains the following options:
CACHE_TYPE=LRU;PAGE_SIZE=16384;MVCC=TRUE;LOCK_MODE=0;UNDO_LOG=0;LOG=1;DB_CLOSE_DELAY=-1

I think it's either the LOCK_MODE or MVCC that's causing the problems but I don't really know how best to investigate.  Any ideas?

org.h2.jdbc.JdbcSQLException: Row not found when trying to delete from index "TIMESERIES.IDX_METRIC_DATA_START_TIME: ( /* key:1 */ 10502, TIMESTAMP '2012-04-24 22:00:00.0', TIMESTAMP '2012-04-25 00:50:00.0', X'aced000573720020636f6d2e63612e63686f7275732e74696d657365726965732e54534172726179018c63d06105fca80200054a0007656e6454696d654900066c656e6774684a0009737461727454696d654c000c636c6f636b4d656d656e746f74002a4c636f6d2f63612f63686f7275732f74696d657365726965732f6e756d657269632f4d656d656e746f3b4c000b646174614d656d656e746f71007e0001787000000136e6f9eac00000002300000136e65e47007372003a636f6d2e63612e63686f7275732e74696d657365726965732e6e756d657269632e4e756d62657244656c74614f7574707574244d656d656e746f7390f51c1bf5d3fc0200014c00076d656d656e746f71007e0001787073720038636f6d2e63612e63686f7275732e74696d657365726965732e6e756d657269632e4e756d626572524c454f7574707574244d656d656e746ff49d0987111300c102000549000a63757272656e74496e744a000b63757272656e744c6f6e674900066c656e67746849000473697a654c00076d656d656e746f71007e000178700000000000000000000493e0000000220000002d7372003c636f6d2e63612e63686f7275732e74696d657365726965732e6e756d657269632e4e756d6265725061636b696e674f7574707574244d656d656e746f40a3b5b30dd1f4770c00007870770400000003737200106a6176612e7574696c2e4269745365746efd887e3934ab210200015b0004626974737400025b4a7870757200025b4a782004b512b1759302000078700000000413c39b732f23805300000000000124f800000000000000000000000000000000787371007e00077704000000007371007e00097571007e000c00000010e5e77179dc5e7397e79179de5e77979d9179e45e79179e4579e85e7a179e85e7ea5e7a179e85e7a15e7c179f05e7c1797d979f05e7c179f0979f65e7d979f65e9fc5e7f179f65e7d0027f179fc5e7f1700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000078')"; SQL statement:
DELETE FROM timeseries.metric_data WHERE end_time < ? LIMIT 100 [90112-162]
    at org.h2.message.DbException.getJdbcSQLException(DbException.java:329)
    at org.h2.message.DbException.get(DbException.java:169)
    at org.h2.message.DbException.get(DbException.java:146)
    at org.h2.index.PageBtreeLeaf.remove(PageBtreeLeaf.java:224)
    at org.h2.index.PageBtreeNode.remove(PageBtreeNode.java:324)
    at org.h2.index.PageBtreeIndex.remove(PageBtreeIndex.java:241)
    at org.h2.index.MultiVersionIndex.remove(MultiVersionIndex.java:170)
    at org.h2.table.RegularTable.removeRow(RegularTable.java:361)
    at org.h2.command.dml.Delete.update(Delete.java:93)
    at org.h2.command.CommandContainer.update(CommandContainer.java:73)
    at org.h2.command.Command.executeUpdate(Command.java:226)
    at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:143)
    at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:129)
    at org.jboss.resource.adapter.jdbc.CachedPreparedStatement.executeUpdate(CachedPreparedStatement.java:96)
    at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:365)
    at com.ca.chorus.db.LeakDetectingPreparedStatement.executeUpdate(LeakDetectingPreparedStatement.java:59)
    at com.ca.chorus.db.DbExecutor$11.call(DbExecutor.java:622)
    at com.ca.chorus.db.DbExecutor$11.call(DbExecutor.java:611)
    at com.ca.chorus.aop.guice.IPerfTracer$1.trace(IPerfTracer.java:25)
    at com.ca.chorus.db.DbExecutor.executeUpdate(DbExecutor.java:610)
    at com.ca.chorus.db.DbExecutor.executeUpdate(DbExecutor.java:572)
    at com.ca.chorus.timeseries.metricpoller.MetricCleanupRunner$1.call(MetricCleanupRunner.java:65)
    at com.ca.chorus.timeseries.metricpoller.MetricCleanupRunner$1.call(MetricCleanupRunner.java:58)
    at com.ca.chorus.server.transaction.TransactionRunner.invoke(TransactionRunner.java:23)
    at com.ca.chorus.server.transaction.TransactionRunner$$EnhancerByGuice$$972c4997.CGLIB$invoke$0(<generated>)
    at com.ca.chorus.server.transaction.TransactionRunner$$EnhancerByGuice$$972c4997$$FastClassByGuice$$d886fd1c.invoke(<generated>)
    at com.google.inject.internal.cglib.proxy.$MethodProxy.invokeSuper(MethodProxy.java:228)
    at com.google.inject.internal.InterceptorStackCallback$InterceptedMethodInvocation.proceed(InterceptorStackCallback.java:72)
    at com.ca.chorus.aop.guice.IPerfTracer$1.trace(IPerfTracer.java:19)
    at com.ca.chorus.server.transaction.TransactionalMethodInterceptor.invoke(TransactionalMethodInterceptor.java:31)
    at com.google.inject.internal.InterceptorStackCallback$InterceptedMethodInvocation.proceed(InterceptorStackCallback.java:72)
    at com.google.inject.internal.InterceptorStackCallback.intercept(InterceptorStackCallback.java:52)
    at com.ca.chorus.server.transaction.TransactionRunner$$EnhancerByGuice$$972c4997.invoke(<generated>)
    at com.ca.chorus.timeseries.metricpoller.MetricCleanupRunner.run(MetricCleanupRunner.java:57)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:482)
    at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:362)
    at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:189)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:189)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1121)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:614)
    at java.lang.Thread.run(Thread.java:769)

[Mark Addleman]

FYI - For this app, I care much more about performance than for transaction consistency or even integrity.  I'm willing to some data as long as the database doesn't become completely corrupted.  That's why I am using LOCK_MODE=0 and UNDO_LOG=0. 

[Thomas Mueller]

Hi,

> I think it's either the LOCK_MODE or MVCC that's causing the problems but I don't really know how best to investigate.

Most likely it's LOCK_MODE=0 or UNDO_LOG=0. Those are dangerous. See
the FAQ and documentation for details.

Regards,
Thomas

[Mark Addleman]

Thanks, Thomas

On Thursday, April 26, 2012 9:36:41 AM UTC-7, Mark Addleman wrote: