Red Hat Bugzilla – Bug 876551
DB2 & ee6 bundle & human tasks - SQLCODE=-302
Last modified: 2016-09-20 01:16:17 EDT
Created attachment 644796 [details] server log from the test suite Description of problem: I'm using EAP 6.0 and BRMS ee6 deployable bundle with DB2-97 database. (I'm testing this via the Console.) Whenever a new process instance is being created for a process with human task, the task is created but the process instance creation fails with DB2 SQL Error: SQLCODE=-302, SQLSTATE=22001, SQLERRMC=null, DRIVER=4.13.80. Everything runs fine with EAP 5.1 and "basic" deployable bundle on DB2 and also with the ee6 bundle on other databases. Version-Release number of selected component (if applicable): BRMS 5.3.1 ER4 Steps to Reproduce: 1. Create a process with some human task. 2. Start a new instance of the process (via Console). 3. Fill in the process taskform. Actual results: Server logs show DB2 SQL Error: SQLCODE=-302, SQLSTATE=22001, SQLERRMC=null, task can be accessed (completed, released) but process seems not to be created. Additional info: ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (http-localhost/127.0.0.1:8080-6) DB2 SQL Error: SQLCODE=-302, SQLSTATE=22001, SQLERRMC=null, DRIVER=4.13.80 ... WARN [com.arjuna.ats.arjuna] (http-localhost/127.0.0.1:8080-6) ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffff0a105875:-2c7cda9e:50a369a0:33e, org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization@7636d845 >: javax.persistence.PersistenceException: org.hibernate.exception.DataException: DB2 SQL Error: SQLCODE=-302, SQLSTATE=22001, SQLERRMC=null, DRIVER=4.13.80 ... ... at org.jbpm.integration.console.CommandDelegate.startProcess(CommandDelegate.java:120) [jbpm-gwt-core-5.3.1.BRMS-ER4.jar:5.3.1.BRMS-ER4] ...
Links/info found: http://stackoverflow.com/questions/9625336/sqlexception-db2-sql-error-sqlcode-302-sqlstate-22001-sqlerrmc-null Search for code 22001: http://pic.dhe.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=%2Fcom.ibm.db2.luw.messages.doc%2Fdoc%2Frdb2stt.html Initial thoughts: blob definition in the HT schema is not long enough and there's a value longer than the database field being stored. That's why the following annotation has been added in the HT schema: @Lob @Column(length=65535) This ensures that DB2 creates/uses a blob field in the database of the appropriate length, sinde DB2 has multiple different BLOB types and by default uses the smallest one (256? ). I can't find the appropriate info on an ibm page, but this confirms the blob/length problem: http://stackoverflow.com/questions/10742572/specify-lob-size-in-jpa-entity (Maybe length= needs to be bigger? )
Zuzanna, could you attach the BPMN2 processes that you've used to reproduce this issue?
Created attachment 649270 [details] Guvnor repo export used to test the console Attaching the repo export that we use to test the console with. The bug should be demonstrable on the Evaluation example.
Created attachment 653911 [details] Log showing the DB2 SQL Error: "SQLCODE=-530, SQLSTATE=23503, SQLERRMC=DB2JBPM.TASK.FK27A9A56CE1EF3A" I've pushed the following commit to the 5.2.x which fixes the bug/error shown in the original server.log: http://github.com/droolsjbpm/jbpm/compare/3421015...6e99187 The problem is that while the other Lob fields all had @Column annotations forcing DB2 to use an appropriately large Lob type for the specific field, the ProcessInstanceInfo class is mapped using XML. The <column length="..." /> needed to be added to the JPA 2 XML mapping used in the gwt-console-server EE6 war. However, once that was fixed, another error started showing up (see attached log: "server-SQLCODE-530-TASk-FK-ACTUAL-OWNER.log"). This log references a Foreign Key (constraint) that's placed on the Task.actualOwner_id field (which refers to the id field in the OrganizationalEntity table).
Zuzana, could you confirm that 1. the 302/22001 error is now gone? 2. you're also seeing the 530 error? Thanks, Marco
I was able to confirm that the FK constraint was due to the users not being present in the DB. I've rerun the process without any errors -- setting the BZ to modified.