Its taken me a while to get back to this test and try your recommendations. I
agree that the test code was not conserving resources the way it was written,
but I did not give thought to the fact that the session and publisher was being
created in a transaction and the publish was created in anot
Sorry fot the omission on org.jboss.mq. The following trace appears to have the
mq trace messages from the time the session bean publishes the message, thru
when the client begins to receive it.
thanks,
| 2004-12-20 14:07:42,660 TRACE [org.jboss.mq.SpyMessageProducer] Sending
message [EMAIL
This looks to be more of what you were after. This is the result of the session
EJB throwing EJBException after publishing the JMS message. ...
thanks for taking a look at it.
| 2004-12-17 17:21:01,465 TRACE
[org.jboss.resource.connectionmanager.CachedConnectionManager] popped object:
org.j
I want to make sure I'm doing what you intend to get you the information you've
requested.
* "show trace logging". I'm assuming that means go into conf/log4j.xml and add
the following lines:
|
|
|
|
|
|
|
|
|
|
I also tried TRACE (versus DEBUG above), but
>From what I have come to know "true" means use internal transactions, which
>would require one to use manual calls to commit()/rollback() on the session.
>"false" either means none at all (similar to JDBC autocommit=false) when no
>JTA is active or part of the JTA when using an XAConnection fa
I changed my session to transacted=true (and the printed debug stated this was
the case). However, it worked the same as the transacted=false case.
According to what I've read and experienced with WebLogic JMS, transacted=true
means to use JMS internal transactions (thus use commit()/rollback()
I cannot get my JMS sends to get rolled back as a part of a session bean
setRollbackOnly() or EJBException. I am using:
* transaction required on the session bean
* java:/JmsXA connection factory
* setting local transactions=false on the session
* trying SessionContext.setRollbackOnly()
* trying t
I am looking for an answer as to why my xa-datasource scenario fails to commit and to
determine if there is any configuration changes that can be made to correct the
situation.
I have created a set of DataSource configurations for testing. My test case works fine
with the local-tx-datasource th
