[JBoss JIRA] Created: (JBPM-2128) integrity constraint (********.FK_PROCIN_ROOTTKN) violated - parent key not found
by Jasphior S (JIRA)
integrity constraint (********.FK_PROCIN_ROOTTKN) violated - parent key not found
----------------------------------------------------------------------------------
Key: JBPM-2128
URL: https://jira.jboss.org/jira/browse/JBPM-2128
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Core Engine
Environment: Windows XP, Std Desktop
jBOSS 4.2.2, ORACLE 10, JBoss jBPM3 - Core 3.3.0.GA, EJB3
Reporter: Jasphior S
I face the below exceptions while trying to create a ProcessInstance.....
root cause : javax.ejb.EJBException: org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update
and the other root cause:
java.sql.BatchUpdateException: ORA-02291: integrity constraint (******.FK_PROCIN_ROOTTKN) violated - parent key not found
However, the most annoying part is this occurs inconsistently.
After encountering this problem and after restarting the jboss server the error is gone! Again after a while starts occurring...
I'm not sure about the root cause, but I think the TransactionManager/related configuration has something to do with this...(because this never occurred when I wasn't using any TransactionManager...)
I'm using the below configuration for TransactionManagement in persistence.xml
<property name="hibernate.transaction.factory_class" value="org.hibernate.ejb.transaction.JoinableCMTTransactionFactory"></property>
<property name="hibernate.transaction.manager_lookup_class" value="org.hibernate.transaction.JBossTransactionManagerLookup"></property>
<property name="hibernate.current_session_context_class" value="org.hibernate.context.JTASessionContext"></property>
and below in the jbpm-cfg.xml
<jbpm-context>
<service name="persistence">
<factory>
<bean class="org.jbpm.persistence.db.DbPersistenceServiceFactory">
<field name="isTransactionEnabled">
<false />
</field>
<field name="isCurrentSessionEnabled">
<false />
</field>
</bean>
</factory>
</service>
</jbpm-context>
When I googled abt this problem, I found many with similar issues but, couldn't find a valid solution for this... hence, I'm logging here... If there is any solution/this is fixed(in new releases) pls mention the same.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (JBPM-2138) JBPM_LOG table column 'exception' is too small, throws RE: ORA-01461: can bind a LONG value only for insert into a LONG column
by George Mournos (JIRA)
JBPM_LOG table column 'exception' is too small, throws RE: ORA-01461: can bind a LONG value only for insert into a LONG column
------------------------------------------------------------------------------------------------------------------------------
Key: JBPM-2138
URL: https://jira.jboss.org/jira/browse/JBPM-2138
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: jbpm 3.2.6 on an oracle server, any application server or OS
Reporter: George Mournos
If an action throws an exception, the stack trace is logged in the JBPM_LOG table.
However, in case of a very long stack trace (longer than 4000 characters), this throws an oracle Exception.
"RE: ORA-01461: can bind a LONG value only for insert into a LONG column"
The bug is difficult to trace, since the exception is only thrown at hibernate session.flush() and not at the actual insert...
Actual exception stacktrace that presented the problem was the exception stacktrace of weblogic, 7200 chars. (the jbpm action was executing business logic running in its own transaction).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (JBPM-2139) Concurrency problems with the Join node despite lock="pessimistic"
by George Mournos (JIRA)
Concurrency problems with the Join node despite lock="pessimistic"
------------------------------------------------------------------
Key: JBPM-2139
URL: https://jira.jboss.org/jira/browse/JBPM-2139
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Core Engine
Environment: jbpm 3.2.6, weblogic 9.2.1, oracle 10g
Reporter: George Mournos
We are evaluating jbpm for concurrency.
We created a test case with a lot of concurrency.
The test process has:
* a fork
* 10 nodes with async="true" and
* a join with lock="pessimistic".
In some of the parallel nodes we get the exception:
Caused by: org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [org.jbpm.graph.exe.Token#121]
We checked that the lock mode is persisted correctly and that the join node actually does the lock.UPGRADE.
We attach the testcase, the test process definition, and the full stacktrace.
We enforced a stricter locking strategy, namely locking the process instance for as long as the command executor was working and the test worked ok.
However, we finally dropped this solution because it was creating a lot of row locks and could lead to transaction timeouts and finally chose another solution.
All of our business logic is in nodes with async="true" and goes through the jms executor.
We serialize consumption of jms messages belonging to the same process instance by using a JMS extention of Weblogic, called UnitOfOrder.
WLMessageProducer messageProducer = (WLMessageProducer)session.createProducer(destination);
messageProducer.setUnitOfOrder(processInstance + "");
This workaround could be useful to people working on weblogic.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (JBPM-2167) Group Task Assignment problem- Unable to see task avalaible to all users present in group on console
by Swati S (JIRA)
Group Task Assignment problem- Unable to see task avalaible to all users present in group on console
----------------------------------------------------------------------------------------------------
Key: JBPM-2167
URL: https://jira.jboss.org/jira/browse/JBPM-2167
Project: JBoss jBPM
Issue Type: Support Patch
Security Level: Public (Everyone can see)
Components: Console
Affects Versions: jBPM 3.2.3
Reporter: Swati S
Hi,
I'm using 3.2.3 version. I'm using group(testgroup) in task node assignment expression. I have 3 users in "testgroup" but I dont see this task is available to any of the user from group.
In pooledActor attibute I see group name but in personal /group task I am unable to see. If I assign one of the user role and If I change assignment expression to group(testuser)-->member(mynewrole) then this task gets assigned to user and can see in personal task list. If I add same role to another user then it gives delegationException.
I want this task to be visible on task list of all users from group.
Can anyone help me with that?
I tried using AssignmentHanlderClass. uses assignable.setPooledActors() here again in the pooledActor attribute Users list is available but I dont see task available on each of these user's personal task list.
Your help will be appreciated.
Thanks & Regards,
Swati
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (JBPM-2227) JPDL does not update source.xml when project.
by Sujatha Bharathan (JIRA)
JPDL does not update source.xml when project.
---------------------------------------------
Key: JBPM-2227
URL: https://jira.jboss.org/jira/browse/JBPM-2227
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: GPD
Environment: Window XP with service pack 3
Reporter: Sujatha Bharathan
When i update a task node in my JPDL diagram and create a reminder and set it to 24 hours and said repeat as yes and and the reminder works fine. But when i update the reminder ..say 2 minutes - the original source xml still states 24 hours. I had to manually edit it every time i make changes in the reminder in the task node.
Has anybody had this issue before?
Whenever a reminder email is sent it follows the template definition task-assign from the jbpm.mail.templates.xml - is there a way i can customise and create a reminder differently by specifying different mail templates? How do I then link the task to this template( i dont see any template linking at task node level)
Looking forward to your reply
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (JBPM-2308) 3.2.3 release notes are out of date
by Tom Muldoon (JIRA)
3.2.3 release notes are out of date
-----------------------------------
Key: JBPM-2308
URL: https://jira.jboss.org/jira/browse/JBPM-2308
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: jBPM 3.2.3
Reporter: Tom Muldoon
The release notes contained within the jbpm-jpdl-3.2.3.zip provide migration notes (from 3.1.x to 3.2.x) that are no longer relevant...
- The DUEDATE_ should not be declared as a timestamp; it should be declared as a datetime
- The LOCKTIME_ should not be declared as a timestamp; it should be declared as a datetime
- The RETRIES_ value should be set to 1 (not 0) as part of the insert statement (which migrates the data from jbpm_timer to jbmp_job)
- Foreign keys should be created
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years