[jboss-dev-forums] [Design of JCA on JBoss] - Re: JBossTS/JBossJCA XA/Local transactions

[mark.little@jboss.com]

"weston.price at jboss.com" wrote : anonymous wrote : 
  |   | Why do you believe you need this support? 
  |   | 
  | 
  | I am not saying we 'should' support it. I was trying to point out that JBossTM supported this type of scenario Without it, migration efforts to JBoss5 and new development could become costly. 
  | 

It could, but to follow this reasoning to its logical conclusion, we'd need to provide backward compatibility in other areas, e.g., disabling recovery by default, stopping distributed transactions, no Web Services support, poor documentation? Not a good argument IMO ;-)

anonymous wrote : 
  | Consider a few simple scenarios: 
  | 
  | 1) I have 2 databases both Postgres. Using JBossTS, I cannot use them simultaneously.
  | 

You can if they support 2PC. If they don't, then there is no point in putting them both in a single 2PC transaction anyway. JBossTM may have "supported" this (or allowed it), but it wasn't doing users any favours. What semantics do you think it supported as a result? Not coordinated outcome for sure.

anonymous wrote : 
  | 2) My company has DB2 and we would like to use the thin (db2jcc) driver. This driver does not support native XA, but we still want to us it and use multiple LocalTX datasources in our EJBs.
  | 

Same as above. I think you're ignoring one of the reason for using transactions: guaranteed consistent outcome across participants. Sure, JBossTM let you put N one-phase aware participants into a transaction, but it didn't/couldn't give you any guarantees in the presence of failures. In that case, there really is little point in doing the work within a transaction: you get the overhead of 2PC without any of the benefits.

If customers think that they are getting benefits from this kind of scenario then I think they are being ill advised. This is an education issue rather than a technical debate.

anonymous wrote : 
  | 3) I have WebSphereMQ, my company cannot afford the non-transactional client I still want to use the product. I have to be very careful about what scenarios I can use it withing JBoss5, where before I did not.
  | 

No. Before we simply ignored the fact that failures would result in non-atomic outcomes!

anonymous wrote : 
  | 4) I have n+ applications written on JBoss4 that use 2 or more LocalTx resources. My DB provider does not support XA, or we do not want to pay for XA capability. What do I do? 
  | 

You understand what the limitations of that scenario are. If you still want to call commit or rollback on multiple resources/JDBC 1.0 drivers, then write a wrapper class that you register them with rather than mis-using the transaction layer, and add commit/rollback methods to that. Call it a Unit of Work (which is pretty much what IBM did back in the 70's). Or, more likely, point them at the WS-BA model, which is supported outside of Web Services at the native level and uses a forward compensation model. This works on the assumption that failures don't happen often and it's easier to roll forward during recovery. The old JBossTM implementation worked in a similar way ;-)

anonymous wrote : 
  | anonymous wrote : 
  |   | Now obviously not ever participant in existance is 2PC-aware. In that case, as with other products such as Tux and CICS, we support LRCO.
  |   | 
  | 
  | Sigh...yes I know this, but thanks for the good news!. Lord knows I would never have cause to know something like this when working on JCA. Thanks for the clarification.
  | 

I did say it was obvious. However, since you appear(ed) to be advocating something that was also obviously a very bad idea, I thought it best not to leave anything to chance!

Just because something CAN BE DONE, doesn't mean it SHOULD BE DONE. Fine, we were able to support this approach in JBossTM, but that doesn't make it right. If there are customers out there who really do need this capability and understand that this is a broken approach, then we can look at some kind of support, but it won't be a transaction, it won't be JTA compliant, or JTS compliant!

anonymous wrote : 
  | Let me reiterate, I am not advocating this type of configuration. I am simple stating that previous versions of JBoss supported this and anyone attempting to migrate their applications will most likely run into this issue.
  | 

Anyone attempting to migrate an application will most likely run into the recovery aspect first ;-)

anonymous wrote : 
  | Theory and 'best practices' are great, but in the long run, when rubber hits the road these types of scenarios can present real problems in terms of backwards compatibilty.
  | 

Let's wait and see. But this isn't related to "theory". It's a core requirement of any ACID transaction system to guarantee consistency in the presence of failures or concurrent access to data. Repeat after me: A stands for ATOMIC ;-)

anonymous wrote : 
  | anonymous wrote : 
  |   | There's a really good book on the subject: 
  |   | 
  | 
  | Goddamnit! 
  | 
  | Why does everyone at JBoss feel the need to write up a pontificating book report when the subject of transactions comes up? What's more annoying is that you damn good and well that I own, and have read, this sparkling tome of wisom. In fact we have discussed it! So, I am not sure what you were driving at by posting that in here other than as a shameless plug. 
  | 

It's Christmas. It would make a very good present ;-) I've a wife and two kids to support, plus 3 cats. GO AND BUY IT AGAIN. You know if makes sense ;-)

anonymous wrote : 
  | Maybe if I ask nice enough I can get your autograph too! God knows I would love to have a signed copy of this masterpiece ;-)
  | 

Autographs are $50 a piece ;-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989004#3989004

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989004