[RTC] Error creating repository structure through Java API in 5.0.1

We running some tests in 5.0.1 before upgrading from 4.0.6. One of these tests is to create a project area based on a process template that uses a participant to create a default folder structure inside a the component at the time the project area is being created. However we are getting an error that freezes the project area creation process. This same code is working fine in 4.0.6.
After some debugging, we noticed that the freeze occurs in the line that creates a changeset to the flow:

“IChangeSetHandle result = services.getScmService().createChangeSetForStream(workspaceHandle, component,changeSetComment, instruction, null, null);”

Checking Derby's log, we found a lock error message, that ultimately causes a timeout:

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)
    ... 74 more
Caused by: ERROR 40XL1: A lock could not be obtained within the time requested
    at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
    at org.apache.derby.impl.services.locks.ConcurrentLockSet.lockObject(Unknown Source)
    at org.apache.derby.impl.services.locks.ConcurrentLockSet.zeroDurationLockObject(Unknown Source)
    at org.apache.derby.impl.services.locks.AbstractPool.zeroDurationlockObject(Unknown Source)
    at org.apache.derby.impl.services.locks.ConcurrentPool.zeroDurationlockObject(Unknown Source)
    at org.apache.derby.impl.store.raw.xact.RowLocking2nohold.lockRecordForRead(Unknown Source)
    at org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.lockPositionForRead(Unknown Source)
    at org.apache.derby.impl.store.access.conglomerate.GenericScanController.fetchRows(Unknown Source)
    at org.apache.derby.impl.store.access.heap.HeapScan.fetchNextGroup(Unknown Source)
    at org.apache.derby.impl.sql.execute.BulkTableScanResultSet.reloadArray(Unknown Source)
    at org.apache.derby.impl.sql.execute.BulkTableScanResultSet.getNextRowCore(Unknown Source)
    at org.apache.derby.impl.sql.execute.JoinResultSet.openCore(Unknown Source)
    at org.apache.derby.impl.sql.execute.JoinResultSet.openCore(Unknown Source)
    at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(Unknown Source)
    at org.apache.derby.impl.sql.execute.SortResultSet.openCore(Unknown Source)
    at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(Unknown Source)
    at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(Unknown Source)
    at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown Source)
    at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source)
    ... 68 more
2014-11-17 12:56:09,020 [ccm: AsynchronousTaskRunner-1 @@ 12:55] ERROR sqlExceptionLogger                                  - CRJAZ1318E O servidor não pôde se conectar ao banco de dados. Tente a operação novamente.
Transaction rollback

After some searching in jazz.net, we found this defect: https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=329721. According to the user, the same error happened when he upgraded to 4.0.7, and turns out it seems to be an issue in Derby. He solved the problem when he moved to DB2. So we installed IBM DB2 Express-C Version 10.1.0.2 for Linux in the test environment we ran the same test. Once again we got the same error: code freezes at the same line.
Is this a known issue? Is there any workaround? Could it have something to do with the fact we are using these small scale databases? Could it be a bug in our code?

Thanks in advance!