[Design of JCA on JBoss] - Re: Problems JCA JMS inflow issue and tx NotSupported
by weston.price＠jboss.com
As I have said, I believe more than a few times now, the 4.0.5 code was backported randomly and really should never have been done (believe me, I yelled and screamed about this for quite awhile but to no avail). The code in HEAD should really be ported or installed as a patch.
Please note, just because JCA starts/terminates a transaction does not mean that the onMessage method executes in this context. If NotSupported or BMT is used, the EJB container will suspend the transaction appropriately.
anonymous wrote :
| Hmmm, it seems that if I omit the acknowledge-mode from the MDB deployment descriptor when using BMT, then it defaults to transacted.
|
No, it's not. acknowledgement modes are used only in the case of a *non* tranascted session. The spec is merely saying that if the client is using a transacted session, then the ack mode is AUTO_ACKNOWLEDGE which is just simply a convention in this case as has no overall effect.
anonymous wrote :
| Instead, it should be creating a non transacted session, on a non xa connection and not calling commit at the end since it's non transacted.
|
No, it doesn't.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001387#4001387
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001387
19 years, 2 months
[Design of JBoss jBPM] - committing content from our
by camunda
Hi everybody.
First of all I am very sorry I haven't done anything on that issue for the last 4 months, even if I have planned to do that! But I was very busy with other projects :-(
My plan is now to
1.) contribute some jbpm commands (because we had written some additional logic like updating a process version in special cricumstances) to get rid of our own service-classes.
2.) Get the Swing AdminClient (Screenshots on http://www.camunda.com/toolkit_for_jbpm/tk-jbpm-screenshots.html) work with the default Command mechanism in jBPM
3.) Extract the generic code we used for a Swing-Tasklist and opening tasks in Swing panels to form a generic framework for Swing applications working with jBPM
So I will start with the first issue the next time.
One problem is maybe, that we have some very pragmatic commands in our toolkit (e.g. updating the process version of a running instance in the case, that there is a note with the same name in the new version), which we also want to contribute. Would that be OK for you?
Maybe I can make a package org.jbpm.command.experimental for that?
A second thing is, that I need for Swing-applications some GetProcess/Task/.../Command's, because I need to preload some parts of the objects graph before give the result to the client. But the advantage is, we can get rid of any DataTransferObject's we currently use in the AdminClient. I will just add them to the core, ok?
Also I will not have a JUnit test for every command, even if they are working in some real life applications... But I will work on that issue as soon there is time!
What do you mean on that plan?
Sorry for the long thread!
Bernd.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001352#4001352
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001352
19 years, 2 months
[Design of JCA on JBoss] - Re: Problems JCA JMS inflow issue and tx NotSupported
by timfox
"timfox" wrote :
| Interestingly the same problem occurs with BMT as well even though no transaction should have been started at all. BMT doesn't count as an "unspecified tx context" so the reasoning for starting a tx there shouldn't apply as it does for CMT.
Hmmm, it seems that if I omit the acknowledge-mode from the MDB deployment descriptor when using BMT, then it defaults to transacted.
This seems to be in contravention to the EJB spec:
15.4.8
anonymous wrote :
| If the acknowledge-mode deployment
| descriptor element is not specified, JMS AUTO_ACKNOWLEDGE semantics are assumed.
|
This would explain the above behaviour: The JCA adaptor is creating an xasession on the xaconnection even though it's BMT (and should be auto_ack since I haven't specified acknowledge-mode), then trying to call commit on it at the end.
Instead, it should be creating a non transacted session, on a non xa connection and not calling commit at the end since it's non transacted.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001333#4001333
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001333
19 years, 2 months
[Design of JCA on JBoss] - Re: Problems JCA JMS inflow issue and tx NotSupported
by timfox
Looking through the 4.0.5 JCA code I think I can see what is happening:
In the CMT case, the onMessage is marked as NotSupported so the JMSServerSession chooses a LocalDemarcationStrategy even though the connection is an XAConnection.
Then bang,
| javax.jms.TransactionInProgressException: Cannot call commit on an XA session
| at org.jboss.jms.client.container.TransactionAspect.handleCommit(TransactionAspect.java:97)
| at org.jboss.aop.advice.org.jboss.jms.client.container.TransactionAspect14.invoke(TransactionAspect14.java)
| at org.jboss.jms.client.delegate.ClientSessionDelegate$commit_8461082169793485964.invokeNext(ClientSessionDelegate$commit_8461082169793485964.java)
| at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:182)
| at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117)
| at org.jboss.jms.client.delegate.ClientSessionDelegate$commit_8461082169793485964.invokeNext(ClientSessionDelegate$commit_8461082169793485964.java)
| at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:69)
| at org.jboss.jms.client.delegate.ClientSessionDelegate$commit_8461082169793485964.invokeNext(ClientSessionDelegate$commit_8461082169793485964.java)
| at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
| at org.jboss.jms.client.delegate.ClientSessionDelegate$commit_8461082169793485964.invokeNext(ClientSessionDelegate$commit_8461082169793485964.java)
| at org.jboss.jms.client.delegate.ClientSessionDelegate.commit(ClientSessionDelegate.java)
| at org.jboss.jms.client.JBossSession.commit(JBossSession.java:165)
| at org.jboss.resource.adapter.jms.inflow.JmsServerSession$LocalDemarcationStrategy.end(JmsServerSession.java:341)
| at org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:260)
| at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:204)
| at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:275)
| at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:743)
|
as the ServerSession tries to
call commit() which clearly will fail.
Interestingly the same problem occurs with BMT as well even though no transaction should have been started at all. BMT doesn't count as an "unspecified tx context" so the reasoning for starting a tx there shouldn't apply as it does for CMT.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001328#4001328
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001328
19 years, 2 months
[Design of JCA on JBoss] - Re: Problems JCA JMS inflow issue and tx NotSupported
by weston.price＠jboss.com
anonymous wrote :
| I suppose for a CMT method in a "Non specified" tx context I guess it is legal to run it in a local tx (although I'm not sure why that was chosen rather than just having no tx).
|
To support redelivery of a message for an MDB that throws a RuntimeException in a 'non specified transaction context'.
Being that JCA has to be JMS provider agnostic if a listener throws a runtime exception and the transactional attribute is NotSupported (BMT or CMT) and the client wants the message to be redelivered, the only way to achieve this in a neutral manner is to use transactions. Note, neither the JMS or the EJB spec prohibit this being that the transactional handling of a receipt of a message in an unspecified context is left up to the vendor.
Unfortunately, the 4.0.5 code base, as opposed to the refactoring in HEAD, uses a 1PC optimization on an XAResource which was not a good design to begin with. The latest code uses local JMS transactions both for performance reasons, as well as for clarity in the BMT/CMT NotSupported scenario.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001297#4001297
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001297
19 years, 2 months