Svetlana Dorokhova added a comment - 19/Oct/17 2:07 PM - edited Performance test consisted of the following: 1. FULL history level 2. Process looks like this: BpmnModelInstance process = Bpmn.createExecutableProcess( "process" ) .startEvent() .serviceTask() .camundaClass(NoopDelegate. class. getName()) .camundaAsyncAfter() .serviceTask() .camundaClass(UpdateVarDelegate. class. getName()) .camundaAsyncAfter() .serviceTask() .camundaClass(DeleteVarDelegate. class. getName()) .endEvent() .done(); 3. Process is started with 500 process variables. 1st Service task does nothing, but the transaction is committed after it is completed (asyncAfter). 2nd service task update all 500 process variables with new values and the transaction is committed afterwards. 3rd service task removes all the variables and process finishes. The testing was done with the help of QA Performance test suite. It was running the test in 2 threads with 50 repeations. The result are the following: - Oracle 12 Mysql 5.7.17 SQL Server 2014 SIMPLE mode 196696 135528 264003 BATCH mode 58012 128714 94147 It looks like MySQL does not distinguish batch and not batch operations, but SQL Server and Oracle do.

Svetlana Dorokhova added a comment - 20/Oct/17 5:46 PM - edited Won't work for Oracle < 12. http://docs.oracle.com/cd/E11882_01/java.112/e16548/oraperf.htm#JJDBC28754 For a prepared statement batch, it is not possible to know the number of rows affected in the database by each individual statement in the batch. Therefore, all array elements have a value of -2. According to the JDBC 2.0 specification, a value of -2 indicates that the operation was successful but the number of rows affected is unknown. https://docs.oracle.com/database/121/JJDBC/oraperf.htm#JJDBC28773 For a prepared statement batch, the array contains the actual update counts indicating the number of rows affected by each operation. This means that we won't be able to use optimistic locking with Batch processing switched on on Oracle earlier than v. 12.