4:07 p.m.
Complete JTA transaction refactoring
------------------------------------
Key: JBPM-2339
URL: https://jira.jboss.org/jira/browse/JBPM-2339
Project: JBoss jBPM
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: Bernd Ruecker
Assignee: Tom Baeyens
Priority: Critical
Fix For: jBPM 4.0
After the JTA refactoring there are two problems left which have to be fixed.
1.) The JtaTransactionInterceptor should work even if there is already running JTA
transaction. Currently a exception is thrown that there is a transaciton ACTIVE. Instead
of that it should just use it and do not create a own one.
2.) Suspending the transaction shouldn't be done in JtaTransactionInterceptor like it
is done at the moment. The use case is to support nested transactions for the job executor
(where it decrements the counter and maybe stores exceptions). The necessary code should
be placed in the JobExecutor (so it should use Transaction.suspend directly), so it is at
the right place. The current implementation with suspending every COMMITTED transaction it
finds in the JtaTransactionInterceptor is hacky.
--
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
12:39 p.m.
New subject: [JBoss JIRA] Commented: (JBPM-2339) Complete JTA transaction refactoring
[
https://jira.jboss.org/jira/browse/JBPM-2339?page=com.atlassian.jira.plug...
]
Bernd Ruecker commented on JBPM-2339:
-------------------------------------
Another thing which need some thought is how to lookup the UserTransaction from JNDI.
The safe choice is in my eyes to just look it from global jndi
(ctx.lookup("UserTransaction")) instead of the
"java:/comp/UserTransaction" like it is in the current code base. Because that
does only work in some components and if they are configured correctly.
Complete JTA transaction refactoring
------------------------------------
Key: JBPM-2339
URL: https://jira.jboss.org/jira/browse/JBPM-2339
Project: JBoss jBPM
Issue Type: Task
Security Level: Public(Everyone can see)
Reporter: Bernd Ruecker
Assignee: Tom Baeyens
Priority: Critical
Fix For: jBPM 4.0
After the JTA refactoring there are two problems left which have to be fixed.
1.) The JtaTransactionInterceptor should work even if there is already running JTA
transaction. Currently a exception is thrown that there is a transaciton ACTIVE. Instead
of that it should just use it and do not create a own one.
2.) Suspending the transaction shouldn't be done in JtaTransactionInterceptor like it
is done at the moment. The use case is to support nested transactions for the job executor
(where it decrements the counter and maybe stores exceptions). The necessary code should
be placed in the JobExecutor (so it should use Transaction.suspend directly), so it is at
the right place. The current implementation with suspending every COMMITTED transaction it
finds in the JtaTransactionInterceptor is hacky.
--
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
1:19 p.m.
New subject: [JBoss JIRA] Updated: (JBPM-2339) Complete JTA transaction refactoring
[
https://jira.jboss.org/jira/browse/JBPM-2339?page=com.atlassian.jira.plug...
]
Heiko Braun updated JBPM-2339:
------------------------------
JBoss Forum Reference:
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=157322
Priority: Blocker (was: Critical)
Complete JTA transaction refactoring
------------------------------------
Key: JBPM-2339
URL: https://jira.jboss.org/jira/browse/JBPM-2339
Project: JBoss jBPM
Issue Type: Task
Security Level: Public(Everyone can see)
Reporter: Bernd Ruecker
Assignee: Tom Baeyens
Priority: Blocker
Fix For: jBPM 4.0
After the JTA refactoring there are two problems left which have to be fixed.
1.) The JtaTransactionInterceptor should work even if there is already running JTA
transaction. Currently a exception is thrown that there is a transaciton ACTIVE. Instead
of that it should just use it and do not create a own one.
2.) Suspending the transaction shouldn't be done in JtaTransactionInterceptor like it
is done at the moment. The use case is to support nested transactions for the job executor
(where it decrements the counter and maybe stores exceptions). The necessary code should
be placed in the JobExecutor (so it should use Transaction.suspend directly), so it is at
the right place. The current implementation with suspending every COMMITTED transaction it
finds in the JtaTransactionInterceptor is hacky.
--
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
8:04 p.m.
New subject: [JBoss JIRA] Commented: (JBPM-2339) Complete JTA transaction refactoring
[
https://jira.jboss.org/jira/browse/JBPM-2339?page=com.atlassian.jira.plug...
]
Bernd Ruecker commented on JBPM-2339:
-------------------------------------
When using the remote CommandService with the current code base I get a:
20:01:56,468 ERROR [LogInterceptor] RuntimeException in method: public abstract
java.lang.Object
org.jbpm.enterprise.internal.ejb.RemoteCommandExecutor.execute(org.jbpm.api.cmd.Command)
throws java.rmi.RemoteException:
org.jbpm.pvm.internal.wire.WireException: couldn't initialize object
'org.jbpm.pvm.internal.identity.impl.IdentitySessionImpl': Unable to locate
current JTA transaction
at
org.jbpm.pvm.internal.wire.descriptor.ObjectDescriptor.initialize(ObjectDescriptor.java:233)
at
org.jbpm.pvm.internal.wire.WireContext.performInitialization(WireContext.java:537)
at org.jbpm.pvm.internal.wire.WireContext.initialize(WireContext.java:499)
at org.jbpm.pvm.internal.wire.WireContext.create(WireContext.java:453)
at org.jbpm.pvm.internal.wire.WireContext.create(WireContext.java:441)
at org.jbpm.pvm.internal.wire.WireContext.get(WireContext.java:421)
at org.jbpm.pvm.internal.wire.WireContext.get(WireContext.java:331)
at org.jbpm.pvm.internal.wire.WireContext.get(WireContext.java:707)
at org.jbpm.pvm.internal.env.BasicEnvironment.get(BasicEnvironment.java:153)
at org.jbpm.pvm.internal.env.BasicEnvironment.get(BasicEnvironment.java:144)
at
org.jbpm.pvm.internal.identity.cmd.CreateGroupCmd.execute(CreateGroupCmd.java:47)
at
org.jbpm.pvm.internal.identity.cmd.CreateGroupCmd.execute(CreateGroupCmd.java:32)
at
org.jbpm.pvm.internal.svc.DefaultCommandService.execute(DefaultCommandService.java:42)
at
org.jbpm.pvm.internal.tx.jta.JtaTransactionInterceptor.execute(JtaTransactionInterceptor.java:76)
at
org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:54)
at
org.jbpm.enterprise.internal.ejb.CommandExecutorSLSB.execute(CommandExecutorSLSB.java:102)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
at
org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
...
Complete JTA transaction refactoring
------------------------------------
Key: JBPM-2339
URL: https://jira.jboss.org/jira/browse/JBPM-2339
Project: JBoss jBPM
Issue Type: Task
Security Level: Public(Everyone can see)
Reporter: Bernd Ruecker
Assignee: Tom Baeyens
Priority: Blocker
Fix For: jBPM 4.0
After the JTA refactoring there are two problems left which have to be fixed.
1.) The JtaTransactionInterceptor should work even if there is already running JTA
transaction. Currently a exception is thrown that there is a transaciton ACTIVE. Instead
of that it should just use it and do not create a own one.
2.) Suspending the transaction shouldn't be done in JtaTransactionInterceptor like it
is done at the moment. The use case is to support nested transactions for the job executor
(where it decrements the counter and maybe stores exceptions). The necessary code should
be placed in the JobExecutor (so it should use Transaction.suspend directly), so it is at
the right place. The current implementation with suspending every COMMITTED transaction it
finds in the JtaTransactionInterceptor is hacky.
--
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
12:27 p.m.
New subject: [JBoss JIRA] Commented: (JBPM-2339) Complete JTA transaction refactoring
[
https://jira.jboss.org/jira/browse/JBPM-2339?page=com.atlassian.jira.plug...
]
Bernd Ruecker commented on JBPM-2339:
-------------------------------------
To make the last comment more concrete, this happens AFTER I fixed the
JtaTransactionInterceptor to use existing transactions if they are available.
I can get rid of it, when I switch the "transaction-type" back to
"Container" for the Command Executor SLSB.
Complete JTA transaction refactoring
------------------------------------
Key: JBPM-2339
URL: https://jira.jboss.org/jira/browse/JBPM-2339
Project: JBoss jBPM
Issue Type: Task
Security Level: Public(Everyone can see)
Reporter: Bernd Ruecker
Assignee: Tom Baeyens
Priority: Blocker
Fix For: jBPM 4.0
After the JTA refactoring there are two problems left which have to be fixed.
1.) The JtaTransactionInterceptor should work even if there is already running JTA
transaction. Currently a exception is thrown that there is a transaciton ACTIVE. Instead
of that it should just use it and do not create a own one.
2.) Suspending the transaction shouldn't be done in JtaTransactionInterceptor like it
is done at the moment. The use case is to support nested transactions for the job executor
(where it decrements the counter and maybe stores exceptions). The necessary code should
be placed in the JobExecutor (so it should use Transaction.suspend directly), so it is at
the right place. The current implementation with suspending every COMMITTED transaction it
finds in the JtaTransactionInterceptor is hacky.
--
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
3:10 p.m.
New subject: [JBoss JIRA] Commented: (JBPM-2339) Complete JTA transaction refactoring
[
https://jira.jboss.org/jira/browse/JBPM-2339?page=com.atlassian.jira.plug...
]
Tom Baeyens commented on JBPM-2339:
-----------------------------------
heiko, can you check if my latest commit fixed the problem ?
Complete JTA transaction refactoring
------------------------------------
Key: JBPM-2339
URL: https://jira.jboss.org/jira/browse/JBPM-2339
Project: JBoss jBPM
Issue Type: Task
Security Level: Public(Everyone can see)
Reporter: Bernd Ruecker
Assignee: Tom Baeyens
Priority: Blocker
Fix For: jBPM 4.0
After the JTA refactoring there are two problems left which have to be fixed.
1.) The JtaTransactionInterceptor should work even if there is already running JTA
transaction. Currently a exception is thrown that there is a transaciton ACTIVE. Instead
of that it should just use it and do not create a own one.
2.) Suspending the transaction shouldn't be done in JtaTransactionInterceptor like it
is done at the moment. The use case is to support nested transactions for the job executor
(where it decrements the counter and maybe stores exceptions). The necessary code should
be placed in the JobExecutor (so it should use Transaction.suspend directly), so it is at
the right place. The current implementation with suspending every COMMITTED transaction it
finds in the JtaTransactionInterceptor is hacky.
--
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
4:21 p.m.
New subject: [JBoss JIRA] Work started: (JBPM-2339) Complete JTA transaction refactoring
[
https://jira.jboss.org/jira/browse/JBPM-2339?page=com.atlassian.jira.plug...
]
Work on JBPM-2339 started by Tom Baeyens.
Complete JTA transaction refactoring
------------------------------------
Key: JBPM-2339
URL: https://jira.jboss.org/jira/browse/JBPM-2339
Project: JBoss jBPM
Issue Type: Task
Security Level: Public(Everyone can see)
Reporter: Bernd Ruecker
Assignee: Tom Baeyens
Priority: Blocker
Fix For: jBPM 4.0
After the JTA refactoring there are two problems left which have to be fixed.
1.) The JtaTransactionInterceptor should work even if there is already running JTA
transaction. Currently a exception is thrown that there is a transaciton ACTIVE. Instead
of that it should just use it and do not create a own one.
2.) Suspending the transaction shouldn't be done in JtaTransactionInterceptor like it
is done at the moment. The use case is to support nested transactions for the job executor
(where it decrements the counter and maybe stores exceptions). The necessary code should
be placed in the JobExecutor (so it should use Transaction.suspend directly), so it is at
the right place. The current implementation with suspending every COMMITTED transaction it
finds in the JtaTransactionInterceptor is hacky.
--
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
6:17 p.m.
New subject: [JBoss JIRA] Commented: (JBPM-2339) Complete JTA transaction refactoring
[
https://jira.jboss.org/jira/browse/JBPM-2339?page=com.atlassian.jira.plug...
]
Tom Baeyens commented on JBPM-2339:
-----------------------------------
[15:44:08] Tom Baeyens says: so there is not really a way on how we can have 1 lookup that
works for many environments
[15:44:27] Tom Baeyens says: although
[15:44:58] Tom Baeyens says: the java:comp:/UserTransaction should be available, no ?
[15:45:02] Tom Baeyens says: as it is inside an ejb
[15:47:45] Heiko Braun says: "java:comp:/UserTransaction" is (per spec)
available to any j2ee component. but not the deployer
[15:48:16] Heiko Braun says: "UserTransaction" is available to all components on
jboss
[15:48:24] Heiko Braun says: incl. the deployer
[15:48:34] Heiko Braun says: so, it remains portable
[15:48:40] Heiko Braun says: the way it is now
[15:48:57] Tom Baeyens says: ok
Complete JTA transaction refactoring
------------------------------------
Key: JBPM-2339
URL: https://jira.jboss.org/jira/browse/JBPM-2339
Project: JBoss jBPM
Issue Type: Task
Security Level: Public(Everyone can see)
Reporter: Bernd Ruecker
Assignee: Tom Baeyens
Priority: Blocker
Fix For: jBPM 4.0
After the JTA refactoring there are two problems left which have to be fixed.
1.) The JtaTransactionInterceptor should work even if there is already running JTA
transaction. Currently a exception is thrown that there is a transaciton ACTIVE. Instead
of that it should just use it and do not create a own one.
2.) Suspending the transaction shouldn't be done in JtaTransactionInterceptor like it
is done at the moment. The use case is to support nested transactions for the job executor
(where it decrements the counter and maybe stores exceptions). The necessary code should
be placed in the JobExecutor (so it should use Transaction.suspend directly), so it is at
the right place. The current implementation with suspending every COMMITTED transaction it
finds in the JtaTransactionInterceptor is hacky.
--
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
3:26 p.m.
New subject: [JBoss JIRA] Resolved: (JBPM-2339) Complete JTA transaction refactoring
[
https://jira.jboss.org/jira/browse/JBPM-2339?page=com.atlassian.jira.plug...
]
Tom Baeyens resolved JBPM-2339.
-------------------------------
Resolution: Done
Complete JTA transaction refactoring
------------------------------------
Key: JBPM-2339
URL: https://jira.jboss.org/jira/browse/JBPM-2339
Project: JBoss jBPM
Issue Type: Task
Security Level: Public(Everyone can see)
Reporter: Bernd Ruecker
Assignee: Tom Baeyens
Priority: Blocker
Fix For: jBPM 4.0
After the JTA refactoring there are two problems left which have to be fixed.
1.) The JtaTransactionInterceptor should work even if there is already running JTA
transaction. Currently a exception is thrown that there is a transaciton ACTIVE. Instead
of that it should just use it and do not create a own one.
2.) Suspending the transaction shouldn't be done in JtaTransactionInterceptor like it
is done at the moment. The use case is to support nested transactions for the job executor
(where it decrements the counter and maybe stores exceptions). The necessary code should
be placed in the JobExecutor (so it should use Transaction.suspend directly), so it is at
the right place. The current implementation with suspending every COMMITTED transaction it
finds in the JtaTransactionInterceptor is hacky.
--
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
5472
days inactive
5477
days old
8 comments
3 participants
participants (3)
-
Bernd Ruecker (JIRA) -
Heiko Braun (JIRA)
-
Tom Baeyens (JIRA)