IntegrityDatabase fails with lock-timeout on Derby

During the tests for putting BitRepository version 1.2 in Staging at KB, we encountered the issues on IntegrityService, while it was ingesting data into a Derby IntegrityDatabase.
It seems to be a consequence of using the Batch commits.

The issue should not apply for the PostgreSQL IntegrityDatabase (thus the low priority).

Here is an example of the stack-trace:

Jul 09, 2014 1:22:07 PM com.sun.jersey.spi.container.ContainerResponse mapMappableContainerException
SEVERE: The RuntimeException could not be mapped to a response, re-throwing to the HTTP container
java.lang.IllegalStateException: Could not execute the query 'SELECT last_file_update FROM fileinfo JOIN files ON fileinfo.file_key = files.file_key WHERE files.collection_key = ? AND file_state = ? ORDER BY last_file_update DESC FETCH FIRST ROW ONLY' with the arguments '[1, 0]' on database 'com.mchange.v2.c3p0.impl.NewProxyConnection@4f02f1bf'
...
Caused by: java.sql.SQLException: A lock could not be obtained within the time requested
at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source)
... 52 more