[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-6793) Stream or LOG value cannot be retrieved more than once
[ https://issues.apache.org/jira/browse/DERBY-6793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14313781#comment-14313781 ] Sergey Zolotaryov commented on DERBY-6793: -- I did not look deeper into the problem myself, yesterday I just made the project build in Eclipse correctly (you guys have really odd project structure, perhaps it's legacy, I understand). I'll investigate how we could better handle the binaries. Stream or LOG value cannot be retrieved more than once -- Key: DERBY-6793 URL: https://issues.apache.org/jira/browse/DERBY-6793 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.11.1.1 Environment: does not matter Reporter: Sergey Zolotaryov Attachments: derby-bug.tar.gz Since migrating from derby 10.7.1.1 to 10.11.1.1 really innocent code stopped working: retrieving resultset column data using column names if resultset contains blobs stopped working. I am attaching a maven project with a unit test which proves the issue. If in pom.xml you change the version to 10.7.1.1 the test will pass. We are using spring-jdbc' queryForMap() which traverses resultset metadata and queries attributes by their column labels. Used to work before. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (DERBY-6793) Stream or LOG value cannot be retrieved more than once
[ https://issues.apache.org/jira/browse/DERBY-6793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14313781#comment-14313781 ] Sergey Zolotaryov edited comment on DERBY-6793 at 2/10/15 8:09 AM: --- I did not look deeper into the problem myself, yesterday I just made the project build in Eclipse correctly (you guys have really odd project structure, perhaps it's legacy, I understand). I'll investigate how we could better handle the binaries. To me a fix that just limits functionality is a recognition of insolvency, no offence. was (Author: anydoby): I did not look deeper into the problem myself, yesterday I just made the project build in Eclipse correctly (you guys have really odd project structure, perhaps it's legacy, I understand). I'll investigate how we could better handle the binaries. Stream or LOG value cannot be retrieved more than once -- Key: DERBY-6793 URL: https://issues.apache.org/jira/browse/DERBY-6793 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.11.1.1 Environment: does not matter Reporter: Sergey Zolotaryov Attachments: derby-bug.tar.gz Since migrating from derby 10.7.1.1 to 10.11.1.1 really innocent code stopped working: retrieving resultset column data using column names if resultset contains blobs stopped working. I am attaching a maven project with a unit test which proves the issue. If in pom.xml you change the version to 10.7.1.1 the test will pass. We are using spring-jdbc' queryForMap() which traverses resultset metadata and queries attributes by their column labels. Used to work before. -- 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=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
