db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6792) Could not execute JDBC batch update
Date Thu, 05 Feb 2015 23:47:36 GMT

    [ https://issues.apache.org/jira/browse/DERBY-6792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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)

Mime
View raw message