[jira] [Commented] (DERBY-6792) Could not execute JDBC batch update
[ https://issues.apache.org/jira/browse/DERBY-6792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459384#comment-17459384 ] Richard N. Hillegas commented on DERBY-6792: Without a repro of the problem, it is hard to offer any advice on top of what Myrna suggested in the preceding comments. You may have run out of space on your disk. You may have a corrupt table which needs to be repaired. In the latter case, please see the following advice about how to repair the damage: https://cwiki.apache.org/confluence/display/DERBY/DatabaseCorruption > Could not execute JDBC batch update > --- > > Key: DERBY-6792 > URL: https://issues.apache.org/jira/browse/DERBY-6792 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.8.3.3 > Environment: Derby 10.8.3.3, IBM JAVA 7 SR7, Linux >Reporter: Raja >Priority: Critical > Attachments: Derby_error.txt, derby.log, derbyserver.out > > Original Estimate: 72h > Remaining Estimate: 72h > > We are using Derby v10.8.3.3 for our product CastIron. Our customer is > getting the following error in their production environment. > SEVERE [T-84] [job:96CC8CC6085B45D13583E180C1014E82] > [com.approuter.maestro.vm.Task] Internal error: > org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch > update > org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch > update > at > org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103) > at > org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91) > at > org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43) > at > org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:253) > at > org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:92) > at > org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:87) > at > org.hibernate.jdbc.AbstractBatcher.prepareBatchStatement(AbstractBatcher.java:222) > at > org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2354) > at > org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2307) > at > org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2607) > at > org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:92) > at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:250) > at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:234) > at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:142) > at > org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298) > at > org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27) > at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000) > at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338) > at > org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106) > at > com.approuter.maestro.opera.rdbms.RdbmsSession.commit(RdbmsSession.java:363) > at com.approuter.maestro.vm.Task.commit(Task.java:1136) > at com.approuter.maestro.activities.Invoke.persist(Invoke.java:280) > at sun.reflect.GeneratedMethodAccessor278.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > at > com.approuter.maestro.activities.Instruction.call(Instruction.java:45) > at com.approuter.maestro.vm.Program.call(Program.java:596) > at com.approuter.maestro.vm.Task.run(Task.java:692) > at com.approuter.maestro.vm.Task.run(Task.java:631) > at > com.approuter.maestro.vm.Program$RunnableWrapper.run(Program.java:2207) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:450) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:314) > at java.util.concurrent.FutureTask.run(FutureTask.java:149) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:109) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:217) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) > at java.lang.Thread.run(Thread.java:761) > -- > Need quick
[jira] [Commented] (DERBY-6792) Could not execute JDBC batch update
[ https://issues.apache.org/jira/browse/DERBY-6792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17458970#comment-17458970 ] tysnad commented on DERBY-6792: --- I met the same problem while using mybatis to batch update, Is there a way to resolve this problem? > Could not execute JDBC batch update > --- > > Key: DERBY-6792 > URL: https://issues.apache.org/jira/browse/DERBY-6792 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.8.3.3 > Environment: Derby 10.8.3.3, IBM JAVA 7 SR7, Linux >Reporter: Raja >Priority: Critical > Attachments: Derby_error.txt, derby.log, derbyserver.out > > Original Estimate: 72h > Remaining Estimate: 72h > > We are using Derby v10.8.3.3 for our product CastIron. Our customer is > getting the following error in their production environment. > SEVERE [T-84] [job:96CC8CC6085B45D13583E180C1014E82] > [com.approuter.maestro.vm.Task] Internal error: > org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch > update > org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch > update > at > org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103) > at > org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91) > at > org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43) > at > org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:253) > at > org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:92) > at > org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:87) > at > org.hibernate.jdbc.AbstractBatcher.prepareBatchStatement(AbstractBatcher.java:222) > at > org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2354) > at > org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2307) > at > org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2607) > at > org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:92) > at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:250) > at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:234) > at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:142) > at > org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298) > at > org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27) > at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000) > at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338) > at > org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106) > at > com.approuter.maestro.opera.rdbms.RdbmsSession.commit(RdbmsSession.java:363) > at com.approuter.maestro.vm.Task.commit(Task.java:1136) > at com.approuter.maestro.activities.Invoke.persist(Invoke.java:280) > at sun.reflect.GeneratedMethodAccessor278.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > at > com.approuter.maestro.activities.Instruction.call(Instruction.java:45) > at com.approuter.maestro.vm.Program.call(Program.java:596) > at com.approuter.maestro.vm.Task.run(Task.java:692) > at com.approuter.maestro.vm.Task.run(Task.java:631) > at > com.approuter.maestro.vm.Program$RunnableWrapper.run(Program.java:2207) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:450) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:314) > at java.util.concurrent.FutureTask.run(FutureTask.java:149) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:109) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:217) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) > at java.lang.Thread.run(Thread.java:761) > -- > Need quick analysis and solution. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (DERBY-6792) Could not execute JDBC batch update
[ https://issues.apache.org/jira/browse/DERBY-6792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14347368#comment-14347368 ] Myrna van Lunteren commented on DERBY-6792: --- It's been a while since we heard on this issue, is it still a problem? Could not execute JDBC batch update --- Key: DERBY-6792 URL: https://issues.apache.org/jira/browse/DERBY-6792 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.8.3.3 Environment: Derby 10.8.3.3, IBM JAVA 7 SR7, Linux Reporter: Raja Priority: Critical Attachments: Derby_error.txt, derby.log, derbyserver.out Original Estimate: 72h Remaining Estimate: 72h We are using Derby v10.8.3.3 for our product CastIron. Our customer is getting the following error in their production environment. SEVERE [T-84] [job:96CC8CC6085B45D13583E180C1014E82] [com.approuter.maestro.vm.Task] Internal error: org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch update org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch update at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103) at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43) at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:253) at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:92) at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:87) at org.hibernate.jdbc.AbstractBatcher.prepareBatchStatement(AbstractBatcher.java:222) at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2354) at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2307) at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2607) at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:92) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:250) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:234) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:142) at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000) at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338) at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106) at com.approuter.maestro.opera.rdbms.RdbmsSession.commit(RdbmsSession.java:363) at com.approuter.maestro.vm.Task.commit(Task.java:1136) at com.approuter.maestro.activities.Invoke.persist(Invoke.java:280) at sun.reflect.GeneratedMethodAccessor278.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:611) at com.approuter.maestro.activities.Instruction.call(Instruction.java:45) at com.approuter.maestro.vm.Program.call(Program.java:596) at com.approuter.maestro.vm.Task.run(Task.java:692) at com.approuter.maestro.vm.Task.run(Task.java:631) at com.approuter.maestro.vm.Program$RunnableWrapper.run(Program.java:2207) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:450) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:314) at java.util.concurrent.FutureTask.run(FutureTask.java:149) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:109) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:217) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) at java.lang.Thread.run(Thread.java:761) -- Need quick analysis and solution. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6792) Could not execute JDBC batch update
[ https://issues.apache.org/jira/browse/DERBY-6792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14315493#comment-14315493 ] Mike Matrigali commented on DERBY-6792: --- Another question is does your product fork the derby code in any way, or is just a direct build from some point in time from the derby svn tree. Could not execute JDBC batch update --- Key: DERBY-6792 URL: https://issues.apache.org/jira/browse/DERBY-6792 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.8.3.3 Environment: Derby 10.8.3.3, IBM JAVA 7 SR7, Linux Reporter: Raja Priority: Critical Attachments: Derby_error.txt, derby.log, derbyserver.out Original Estimate: 72h Remaining Estimate: 72h We are using Derby v10.8.3.3 for our product CastIron. Our customer is getting the following error in their production environment. SEVERE [T-84] [job:96CC8CC6085B45D13583E180C1014E82] [com.approuter.maestro.vm.Task] Internal error: org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch update org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch update at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103) at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43) at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:253) at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:92) at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:87) at org.hibernate.jdbc.AbstractBatcher.prepareBatchStatement(AbstractBatcher.java:222) at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2354) at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2307) at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2607) at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:92) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:250) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:234) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:142) at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000) at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338) at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106) at com.approuter.maestro.opera.rdbms.RdbmsSession.commit(RdbmsSession.java:363) at com.approuter.maestro.vm.Task.commit(Task.java:1136) at com.approuter.maestro.activities.Invoke.persist(Invoke.java:280) at sun.reflect.GeneratedMethodAccessor278.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:611) at com.approuter.maestro.activities.Instruction.call(Instruction.java:45) at com.approuter.maestro.vm.Program.call(Program.java:596) at com.approuter.maestro.vm.Task.run(Task.java:692) at com.approuter.maestro.vm.Task.run(Task.java:631) at com.approuter.maestro.vm.Program$RunnableWrapper.run(Program.java:2207) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:450) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:314) at java.util.concurrent.FutureTask.run(FutureTask.java:149) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:109) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:217) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) at java.lang.Thread.run(Thread.java:761) -- Need quick analysis and solution. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6792) Could not execute JDBC batch update
[ https://issues.apache.org/jira/browse/DERBY-6792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14315491#comment-14315491 ] Mike Matrigali commented on DERBY-6792: --- In order to fix this we will need more information, and best would be something reproducible. Seems lowest bar is to make sure we get derby.log that has the error in it. Every extra instance of the error you can provide would give more evidence. Another goal should be to get the query that caused the problem. I think this will be in derby.log - but it may require app changes to catch and report it. I did not go though the big output file, if it is there do post. Could not execute JDBC batch update --- Key: DERBY-6792 URL: https://issues.apache.org/jira/browse/DERBY-6792 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.8.3.3 Environment: Derby 10.8.3.3, IBM JAVA 7 SR7, Linux Reporter: Raja Priority: Critical Attachments: Derby_error.txt, derby.log, derbyserver.out Original Estimate: 72h Remaining Estimate: 72h We are using Derby v10.8.3.3 for our product CastIron. Our customer is getting the following error in their production environment. SEVERE [T-84] [job:96CC8CC6085B45D13583E180C1014E82] [com.approuter.maestro.vm.Task] Internal error: org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch update org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch update at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103) at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43) at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:253) at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:92) at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:87) at org.hibernate.jdbc.AbstractBatcher.prepareBatchStatement(AbstractBatcher.java:222) at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2354) at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2307) at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2607) at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:92) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:250) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:234) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:142) at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000) at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338) at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106) at com.approuter.maestro.opera.rdbms.RdbmsSession.commit(RdbmsSession.java:363) at com.approuter.maestro.vm.Task.commit(Task.java:1136) at com.approuter.maestro.activities.Invoke.persist(Invoke.java:280) at sun.reflect.GeneratedMethodAccessor278.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:611) at com.approuter.maestro.activities.Instruction.call(Instruction.java:45) at com.approuter.maestro.vm.Program.call(Program.java:596) at com.approuter.maestro.vm.Task.run(Task.java:692) at com.approuter.maestro.vm.Task.run(Task.java:631) at com.approuter.maestro.vm.Program$RunnableWrapper.run(Program.java:2207) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:450) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:314) at java.util.concurrent.FutureTask.run(FutureTask.java:149) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:109) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:217) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) at java.lang.Thread.run(Thread.java:761) --
[jira] [Commented] (DERBY-6792) Could not execute JDBC batch update
[ https://issues.apache.org/jira/browse/DERBY-6792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14314463#comment-14314463 ] Myrna van Lunteren commented on DERBY-6792: --- If there is no space issue then this is likely related to the other report we had of a similar error. So it is possible this started due to a bug, but we don't know for sure until/unless we can have an idea of what the sequence of events is that trigger this. There is no fix, nor a way to fix it. Even if we had a fix for the possible bug, it would not fix the database. I can see the following choices for you/your customer: a. continue to limp with the database as is. It will not get better. b. attempt to use the off line compress routine as I described before. There is a possibility this would repair the database, but that is not guaranteed. c. use a back-up. d. create a new database. at d: You *might* be able to salvage data from the old database by exporting data from the database, or manually (e.g. using ij, or by writing a program) selecting data from each table. Could not execute JDBC batch update --- Key: DERBY-6792 URL: https://issues.apache.org/jira/browse/DERBY-6792 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.8.3.3 Environment: Derby 10.8.3.3, IBM JAVA 7 SR7, Linux Reporter: Raja Priority: Critical Attachments: Derby_error.txt, derby.log, derbyserver.out Original Estimate: 72h Remaining Estimate: 72h We are using Derby v10.8.3.3 for our product CastIron. Our customer is getting the following error in their production environment. SEVERE [T-84] [job:96CC8CC6085B45D13583E180C1014E82] [com.approuter.maestro.vm.Task] Internal error: org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch update org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch update at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103) at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43) at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:253) at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:92) at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:87) at org.hibernate.jdbc.AbstractBatcher.prepareBatchStatement(AbstractBatcher.java:222) at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2354) at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2307) at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2607) at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:92) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:250) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:234) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:142) at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000) at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338) at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106) at com.approuter.maestro.opera.rdbms.RdbmsSession.commit(RdbmsSession.java:363) at com.approuter.maestro.vm.Task.commit(Task.java:1136) at com.approuter.maestro.activities.Invoke.persist(Invoke.java:280) at sun.reflect.GeneratedMethodAccessor278.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:611) at com.approuter.maestro.activities.Instruction.call(Instruction.java:45) at com.approuter.maestro.vm.Program.call(Program.java:596) at com.approuter.maestro.vm.Task.run(Task.java:692) at com.approuter.maestro.vm.Task.run(Task.java:631) at com.approuter.maestro.vm.Program$RunnableWrapper.run(Program.java:2207) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:450) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:314) at java.util.concurrent.FutureTask.run(FutureTask.java:149) at
[jira] [Commented] (DERBY-6792) Could not execute JDBC batch update
[ https://issues.apache.org/jira/browse/DERBY-6792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14314156#comment-14314156 ] Raja commented on DERBY-6792: - Hi, There is no space issue in customer environment. Coming to cleaning of Database table, this is difficult as this is customer's production setup and the business logic information is present in the Derby database. Problem re creatable - Partially Yes, this happens almost 2 to 3 times in a week time for customer. Any specific information from the database side we need to get, please guide us. We will collect it and share. Could not execute JDBC batch update --- Key: DERBY-6792 URL: https://issues.apache.org/jira/browse/DERBY-6792 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.8.3.3 Environment: Derby 10.8.3.3, IBM JAVA 7 SR7, Linux Reporter: Raja Priority: Critical Attachments: Derby_error.txt, derby.log, derbyserver.out Original Estimate: 72h Remaining Estimate: 72h We are using Derby v10.8.3.3 for our product CastIron. Our customer is getting the following error in their production environment. SEVERE [T-84] [job:96CC8CC6085B45D13583E180C1014E82] [com.approuter.maestro.vm.Task] Internal error: org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch update org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch update at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103) at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43) at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:253) at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:92) at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:87) at org.hibernate.jdbc.AbstractBatcher.prepareBatchStatement(AbstractBatcher.java:222) at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2354) at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2307) at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2607) at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:92) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:250) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:234) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:142) at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000) at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338) at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106) at com.approuter.maestro.opera.rdbms.RdbmsSession.commit(RdbmsSession.java:363) at com.approuter.maestro.vm.Task.commit(Task.java:1136) at com.approuter.maestro.activities.Invoke.persist(Invoke.java:280) at sun.reflect.GeneratedMethodAccessor278.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:611) at com.approuter.maestro.activities.Instruction.call(Instruction.java:45) at com.approuter.maestro.vm.Program.call(Program.java:596) at com.approuter.maestro.vm.Task.run(Task.java:692) at com.approuter.maestro.vm.Task.run(Task.java:631) at com.approuter.maestro.vm.Program$RunnableWrapper.run(Program.java:2207) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:450) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:314) at java.util.concurrent.FutureTask.run(FutureTask.java:149) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:109) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:217) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) at java.lang.Thread.run(Thread.java:761) -- Need quick analysis and solution. -- This message was sent
[jira] [Commented] (DERBY-6792) Could not execute JDBC batch update
[
https://issues.apache.org/jira/browse/DERBY-6792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14308137#comment-14308137
]
Rick Hillegas commented on DERBY-6792:
--
I see the following error in Derby_error.txt:
{noformat}
Caused by: java.sql.BatchUpdateException: Unexpected no space error while
attempting to update a row on page Page(166,Container(0, 1328)). Values of
internal fields at time of error are as follows: slot = 6, recordId = 640,
newColumnList = {3}, nextColumn = 3, mode = 24, nextPortionHandle = null, page
dump =
---
page id:Page(152,Container(0, 1328))
Overflow: false
PageVersion: 53,625
SlotsInUse:7
DeletedRowCount: 0
PageStatus:1
NextId:9,972
firstFreeByte: 3,445
freeSpace: 601
totalSpace:4,028
spareSpace:20%
minimumRecordSize: 12
PageSize: 4,096
{noformat}
It looks like your customer has filled up their disk.
Hope this helps,
-Rick
Could not execute JDBC batch update
---
Key: DERBY-6792
URL: https://issues.apache.org/jira/browse/DERBY-6792
Project: Derby
Issue Type: Bug
Components: JDBC
Affects Versions: 10.8.3.3
Environment: Derby 10.8.3.3, IBM JAVA 7 SR7, Linux
Reporter: Raja
Priority: Critical
Attachments: Derby_error.txt, derby.log, derbyserver.out
Original Estimate: 72h
Remaining Estimate: 72h
We are using Derby v10.8.3.3 for our product CastIron. Our customer is
getting the following error in their production environment.
SEVERE [T-84] [job:96CC8CC6085B45D13583E180C1014E82]
[com.approuter.maestro.vm.Task] Internal error:
org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch
update
org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch
update
at
org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103)
at
org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91)
at
org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
at
org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:253)
at
org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:92)
at
org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:87)
at
org.hibernate.jdbc.AbstractBatcher.prepareBatchStatement(AbstractBatcher.java:222)
at
org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2354)
at
org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2307)
at
org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2607)
at
org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:92)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:250)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:234)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:142)
at
org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298)
at
org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338)
at
org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106)
at
com.approuter.maestro.opera.rdbms.RdbmsSession.commit(RdbmsSession.java:363)
at com.approuter.maestro.vm.Task.commit(Task.java:1136)
at com.approuter.maestro.activities.Invoke.persist(Invoke.java:280)
at sun.reflect.GeneratedMethodAccessor278.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at
com.approuter.maestro.activities.Instruction.call(Instruction.java:45)
at com.approuter.maestro.vm.Program.call(Program.java:596)
at com.approuter.maestro.vm.Task.run(Task.java:692)
at com.approuter.maestro.vm.Task.run(Task.java:631)
at
com.approuter.maestro.vm.Program$RunnableWrapper.run(Program.java:2207)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:450)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:314)
at java.util.concurrent.FutureTask.run(FutureTask.java:149)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:109)
at
[jira] [Commented] (DERBY-6792) Could not execute JDBC batch update
[ https://issues.apache.org/jira/browse/DERBY-6792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14308279#comment-14308279 ] Myrna van Lunteren commented on DERBY-6792: --- That was my first idea too. However, I did a search and found DERBY-6766, which has the same error. Note that there was no fix for that situation, and the problem would reoccur. Mike had some ideas but no clear solution. DERBY-6766 refers to an earlier issue which did get fixed, DERBY-4923, but looks like the build that you are on (10.8.3.3 - (1557911)) already has this fix.(was backported to the 10.8 branch with revision 1535576). I talked to Mike (because he commented on DERBY-6766) off-line about this issue and he said: In the past when this type of error has happened the page is kind of stuck in that state, so same error will happen over and over again if nothing else on the page changes. From the stack it looks like the problem page is the base page of a row. The locking system of derby requires that updates to base page of a row leave the front of the row on the page. If the update adds more data than fits what is supposed to happen is there should always be enough space in the row so that at worst you just leave a small pointer there and then link to other pages - that pointer is something on order of 16 bytes. What is weird is that there is relatively a lot of free space on the page in this case freeSpace: 601, so not sure what is going on. If it can be reproduced likely would be easy to fix. He also suggested that the problem would only be fixed for new data. So if the database was created with a previous build of 10.8.3.3, the problem could have gotten in and be still there. So, follow up questions are: - as Rick said, is the disk full (or was it full at one point?) - does the problem reoccur, i.e. like Mike suggested, is the database 'stuck'? - is the problem reproducible, i.e. going back to a backup or clean database, does the problem reoccur? Not sure if it's feasible to start with a clean database - this seemed to be happening for the folks of DERBY-6766. - Does the CastIron application log also show the query that caused the problem? Is it similar to DERBY-6766 where there is a combination of updates and inserts? One experiment that might possibly fix the current situation is to run offline compress on the affected table. The table name can be found using the container id mentioned in the error message Rick quoted, so it's container (table, in this case, index would be a 1) with id 1328. To get the table name, use a query like this: SELECT C.CONGLOMERATENUMBER, C.CONGLOMERATENAME, S.SCHEMANAME FROM SYS.SYSCONGLOMERATES C, sys.sysschemas s WHERE CONGLOMERATENUMBER = 1328 AND s.schemaid = C.schemaid ; (documented on this page: http://wiki.apache.org/db-derby/DatabaseConsistencyCheck) Information/syntax on how to run off line compress (call SYSCS_UTIL.SYSCS_COMPRESS_TABLE) can be found in the manuals (see: http://db.apache.org/derby/manuals/index.html#docs_10.8, Reference guide is a good starting point) but it's also mentioned on that same DatabaseConsistencyCheck wiki page mentioned above. Of course, before doing anything with the database you should make a backup, or copy, so we can possibly analyze it. On that note, is there a backup process in place? Could not execute JDBC batch update --- Key: DERBY-6792 URL: https://issues.apache.org/jira/browse/DERBY-6792 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.8.3.3 Environment: Derby 10.8.3.3, IBM JAVA 7 SR7, Linux Reporter: Raja Priority: Critical Attachments: Derby_error.txt, derby.log, derbyserver.out Original Estimate: 72h Remaining Estimate: 72h We are using Derby v10.8.3.3 for our product CastIron. Our customer is getting the following error in their production environment. SEVERE [T-84] [job:96CC8CC6085B45D13583E180C1014E82] [com.approuter.maestro.vm.Task] Internal error: org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch update org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch update at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103) at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43) at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:253) at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:92) at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:87) at
