JBossDeveloper

Rather than go round in circles on this, let me summarise and propose a way forward.

We're all agreed that supporting multiple one-phase aware resources in the scope of the same ACID transaction is bad.

We disagree on whether or not this should be supported by default in JBossTS.

Just because JBossTM did it doesn't mean we should in JBossTS (otherwise we'd be disabling recovery by default, for example). However, we should strive to support backward compatibility where it makes sense. I'm fairly sure we'd disagree on whether this issue makes sense, but let's ignore that.

Until we have a clear need for this, I don't think it's worth expending more effort. Let's wait until there is a need for it and treat it as a feature request. Until JBoss AS 5.0 is in production, people can still use AS 4.0.x and JBossTM to get this capability anyway.

This came in just as I hit submit on my last post.

"weston.price@jboss.com" wrote:
The problem as I see it is in terms of the types of configurations/deployments we have today. Unfortunatley, the use of multiple 1PC resources in JBoss is quite common, in fact, I would go so far as to assert this is the *main* type of configuration we see in client deployments.

This is especially true in the area of JMS where the underlying provider is not required to support XA. Further, there are a variety of JDBC resources (some of the more off beat ones) that don't provide XA adapters either.

If we are indeed saying that we no longer support this, or at the very least, it is not supported with JBossTS then we have a real 're-education' situation on our hands. This is independent of what is *correct* being that we provided this behavior before no matter how broken it may have been.

Again, the cost thing is a factor as well. In many situations, XA costs and many times this does not come cheap.

Of course they always have the option to use JBossTM, but I don't think we want to be in the business of recommending this.

We're not forcing users. We have zero users who need this. The one user who thought he did was able to move to a two-phase approach.

"for the sake or purity"? Well, in this case my definition of "purity" is that it conforms to the protocol and guarantees data consistency in the presence of arbitrary failures. Believe it or not, it is important for customers.

Over the years JBossTS has, by itself, generated multi-million dollar revenues. So it has to work. People trust that it will work correctly.

As I said above, if there really are customers out there who simply cannot do their work any other way then we can look at the best way to support this. But at the moment, I don't see the need.

BTW, let's try not to make this personal. Believe it or not, but the exchange Weston and I had last night was very good natured.

"bill.burke@jboss.com" wrote:

We're not forcing users. We have zero users who need this. The one user who thought he did was able to move to a two-phase approach.

How do you know? What percentage of JBoss users are using JBoss TS currently? Is it even 0.1%?

"for the sake or purity"? Well, in this case my definition of "purity" is that it conforms to the protocol and guarantees data consistency in the presence of arbitrary failures. Believe it or not, it is important for customers.

Who said anything about breaking consistency? Weston was just asking for a damn switch.

Over the years JBossTS has, by itself, generated multi-million dollar revenues. So it has to work. People trust that it will work correctly.

I know JBossTS is kick-ass and rock solid, but you need to understand that we're dealing with orders of magnitude higher user base than Arjuna ever had.

As I said above, if there really are customers out there who simply cannot do their work any other way then we can look at the best way to support this. But at the moment, I don't see the need.

All i know is that when we had that warning message in old TM I was talking about, there were TONS of questions on the forums/mail lists about it. "Why am I getting this warning message every transaction?". Since, until recently I believe, the most popular OSS databases didn't support XA and/or a JDBC XA Driver, my $5.00 bet is that there is a percentage of users who will run smack into this with JBoss 5. I also bet that the majority of Arjuna customers required XA aware resources and thus never used DBs like MySQL and Postgres.

BTW, let's try not to make this personal. Believe it or not, but the exchange Weston and I had last night was very good natured.

Sure. I just get extremely irritated when people talk in absolutes.

Also. Sorry. I'm just not good natured in general. It takes too much effort and I just don't have Weston's talent for wit.

"weston.price@jboss.com" wrote:

Since, until recently I believe, the most popular OSS databases didn't support XA and/or a JDBC XA Driver, my $5.00 bet is that there is a percentage of users who will run smack into this with JBoss 5. I also bet that the majority of Arjuna customers required XA aware resources and thus never used DBs like MySQL and Postgres.

Yes. You hit the proverbial nail right on the head. The big boys (ie Oracle, DB2) I don't worry about so much. Our open source brethren is my main concern especially since we are touting these DB's as an integral component to our unified 'stack'.

"mark.little@jboss.com" wrote:

"weston.price@jboss.com" wrote:

Since, until recently I believe, the most popular OSS databases didn't support XA and/or a JDBC XA Driver, my $5.00 bet is that there is a percentage of users who will run smack into this with JBoss 5. I also bet that the majority of Arjuna customers required XA aware resources and thus never used DBs like MySQL and Postgres.

Yes. You hit the proverbial nail right on the head. The big boys (ie Oracle, DB2) I don't worry about so much. Our open source brethren is my main concern especially since we are touting these DB's as an integral component to our unified 'stack'.

So what you'd be after is something that allowed multiple one-phase resources but whenever a transaction saw more than one of them it said something like "WARNING: YOU ARE SERIOUSLY F*CKING WITH YOUR APPLICATION CONSISTENCY. BACK OFF, TAKE A VACATION AND THEN IF YOU ARE REALLY SURE YOU WANT TO DO THIS THEN CONSIDER YOURSELF WARNED."

"weston.price@jboss.com" wrote:
Classy.

I would leave out the asterix, but that's just me. Plus, being that it is Arjuna we would have to get some form of English vernacular in there

Can we use the word 'bumbershoot' I always liked that one.

"bill.burke@jboss.com" wrote:
Our JCA implementation already does this:

log.warn("Prepare called on a local tx. Use of local transactions on a jta transaction with more than one branch may result in inconsistent data in some cases of failure.");

I thought this message had been turned off, I guess it was just clarified I think the old message was something very cryptic like:

"You are not getting the behavior you expect"

And this confused the shit outta people.