-
1. Re: distributed transactions -- are they or are they not sup
adrian.brock Aug 1, 2005 5:38 PM (in response to gregg_saffell)Ask yourself, how many of those links are from the actual JBoss site?
And while you are at it, ask yourself what the JBoss site actually says:
http://www.jboss.org/wiki/Wiki.jsp?page=JBossJTS
You can be J2EE certified without supporting JTS.
EJB-2.1 Section 19.6.2:
"Interoperability The requirements in this subsection are designed to ensure that when a J2EE container does not support transaction interoperability, the failure modes are well defined so that the integrity of an application s data is not compromised: at worst the transaction is rolled back..."
JTS Work In Progress:
http://jira.jboss.com/jira/browse/JBAS-1421
JBoss with JTS from a partner NOW
http://www.arjuna.com/products/jboss/index.html -
2. Re: distributed transactions -- are they or are they not sup
gregg_saffell Aug 1, 2005 5:49 PM (in response to gregg_saffell)Thanks for the quick reply. Having a definitive answer means more than you know.
The postings regarding tyrex seem to suggest that it was included/recommended at some point in JBoss's history but was subsequently removed/deprecated.
The postings regarding JOTM seem to suggest that it is the recommended open source alternative but I've found no postings that suggest it has been successfully integrated.
I need distributed transaction support in the near term. Are either of the above viable with JBoss 3.2.x or 4.x?
(I'm not averse to doing a little work to make it happen, I'd just like to avoid spending a lot of time only to learn it was never viable to begin with. Also, I'm not talking about a high volume application, just a few concurrent transactions at any given time.)
Thanks again.
Gregg -
3. Re: distributed transactions -- are they or are they not sup
adrian.brock Aug 1, 2005 6:03 PM (in response to gregg_saffell)Tyrex is broken and does not do transaction recovery.
Even the original coder said NOT to use it in production.
Although you can still find the code in the cvs archive, I doubt it even compiles.
JOTM is based upon HOWL of which most people I've spoken to have a low opinion.
I know of posts (which you can find using search) where people have tried to
integrate JOTM and asked for help, but then gave up because:
* They couldn't get it to work
* Got it to work, but didn't give any feedback to tell us
* Gave up trying with no conclusion
If like these other users you go for JOTM and aren't prepared to
contribute the integration back to JBoss, you are on your own.
Useful link:
http://wiki.jboss.org/wiki/Wiki.jsp?page=3rdPartyTM -
4. Re: distributed transactions -- are they or are they not sup
gregg_saffell Aug 1, 2005 6:10 PM (in response to gregg_saffell)If we go for it, I'll be sure to post the results--good, bad, or inconclusive.
Thank you very much both for the reply and for the application server.
Gregg -
5. Re: distributed transactions -- are they or are they not sup
adrian.brock Aug 1, 2005 6:14 PM (in response to gregg_saffell)"Gregg_Saffell" wrote:
I need distributed transaction
It is very seldom you actually need DTM (rather than just XA).
It usually points to bad design and nearly always leads to poor performance.
Besides being a pain to manage.
The only reason we are implementing JTS for JBoss is because people insist they need
it. They are usually wrong. I would never recommend that somebody actually uses it.
But people will always argue that we don't recommend it because we haven't got it.
The answer will be the same when we implement it.
Just like some of the other brain deaths in the spec...
http://wiki.jboss.org/wiki/Wiki.jsp?page=HowCanIAccessADataSourceFromAClient -
6. Re: distributed transactions -- are they or are they not sup
gregg_saffell Aug 1, 2005 6:36 PM (in response to gregg_saffell)That "it only points to bad design" has been posted before and isn't true. We have a distributed application that requires a record to be stored both locally and at a remote site. The redundant storage of the record allows both sites to do their thing even when they can't communicate. Should the two databases get out of sync, the app is compromised. Lastly, they have to communicate over https.
The http invoker servlet is awesome by the way, really came in handy. That's the other piece the worries me though. I'm concerned that even if we do successfully integrate JOTM we'll then only learn that the invoker servlet doesn't propagte the transaction context. Do you know if it will or won't? -
7. Re: distributed transactions -- are they or are they not sup
adrian.brock Aug 1, 2005 6:54 PM (in response to gregg_saffell)"Gregg_Saffell" wrote:
That "it only points to bad design" has been posted before and isn't true. We have a distributed application that requires a record to be stored both locally and at a remote site. The redundant storage of the record allows both sites to do their thing even when they can't communicate. Should the two databases get out of sync, the app is compromised.
My point exactly. Why wouldn't two applications that can't communicate NOT get out of sync. And how are you going to recover them consistently when they can't communicate
with each other? etc.
I'm not going to go further down this road. Your application design is your problem.
Lastly, they have to communicate over https.
The http invoker servlet is awesome by the way, really came in handy. That's the other piece the worries me though. I'm concerned that even if we do successfully integrate JOTM we'll then only learn that the invoker servlet doesn't propagte the transaction context. Do you know if it will or won't?
Why would JOTM/JTS which is CORBA know anything about HTTPS or JBoss's invokers other than RMI/IIOP?
I think it is time you go back and re-read the specs and links that I gave you before,
rather than using me as your search engine. -
8. Re: distributed transactions -- are they or are they not sup
gregg_saffell Aug 1, 2005 7:03 PM (in response to gregg_saffell)I'll take that as a no.
Have a nice day.