-
1. Re: Incorrect Transactional Semantics. Help required !
davidjencks Apr 6, 2003 5:46 PM (in response to divine_comedy)You can't. For complete reliability, you actually need an xa database. Your mdb transactions have 2 participants: (reading) the jms message and writing to the db. If the db commit fails (since it is local only), you are in trouble, since the jms message read has already prepared successfully.
-
2. Re: Incorrect Transactional Semantics. Help required !
divine_comedy Apr 7, 2003 11:50 AM (in response to divine_comedy)Hi David,
Thanks for the reply. I read somewhere in this forum that the XA datasource capabilities for JBoss 3.0.6 and below is nor reliable. Is that true ?
We are an Oracle shop which supports XA obviously, so I would assume that the fix required would be to simply convert my oracle-service.xml to XA configuration is that right ?
Thanks, -
3. Re: Incorrect Transactional Semantics. Help required !
sstephens Apr 7, 2003 5:55 PM (in response to divine_comedy)I am getting the same problem. Can someone please eloborate. I know it has to do with the XA Transaction used by jms and the local transactions used by my Datasource. I have also read that XA Datasources are not stable in Jboss as of 3.0.6.
-
4. Re: Incorrect Transactional Semantics. Help required !
divine_comedy Apr 7, 2003 6:33 PM (in response to divine_comedy)Hi there, can you post the link to that unstable Jboss 3.0.6 ? I read it in this board but I lost the link.
-
5. Re: Incorrect Transactional Semantics. Help required !
davidjencks Apr 9, 2003 11:56 PM (in response to divine_comedy)If you can get xa on 3.0.6 to work, it will probably be stable. 3.0.7 is now out and has a new xa jdbc wrapper (same as 3.2 and 4) that is known to work with Oracle.
Using only xa datasources is a good first step, but if this is extremely mission critical you should be aware that pre jboss 4 the jboss transaction manager cannot recover automatically from failure between prepare and commit. This ability is present but not really tested in jboss 4. You should be able to consult the database logs to see what happened and recover using the db tools, however.