[Design of JCA on JBoss] - Re: JBossTS/JBossJCA XA/Local transactions
by mark.little＠jboss.com
"weston.price(a)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
19 years, 4 months
[Design of JCA on JBoss] - Re: JBossTS/JBossJCA XA/Local transactions
by weston.price＠jboss.com
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.
Consider a few simple scenarios:
1) I have 2 databases both Postgres. Using JBossTS, I cannot use them simultaneously.
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.
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.
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?
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.
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. 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.
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.
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 ;-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988979#3988979
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988979
19 years, 4 months
[Design of JBoss Portal] - Re: Question on UserInterceptor
by joe_the_quick
Hi there,
We already replaced the JAAS-Loginmodule used by portal-server.war.
However, after the successful login I get the following exception:
org.jboss.portal.core.model.NoSuchUserException: No such user No such user TEST_USERNAME
org.jboss.portal.core.impl.user.UserModuleImpl.findUserByUserName(UserModuleImpl.java:123)
I found out that the UserModuleImpl looks up some user information in the JBP_USERS table (first name, last name, additional config info).
QUESTION:
What is the most clever way to replace the UserModuleImpl, as we have
this information already stored in the subject (request.getUserPrincipal()).
If I simply try to replace the "public User findUserById(String id) ..." method, I'm stuck because I don't have access to the principal (stored in the HttpServletRequest), where the required information would be stored.
Since we already did the authentication/authorization I'd like to reuse the data stored in the Principal, to avoid a second method-call for data I already have.
I also tried to comment out all User*-related Interceptors/Modules (includign dependencies in the MailModuleImpl) in jboss-service.xml, but then I get
java.lang.NullPointerException
org.jboss.portal.core.command.CoreComponentRequestContext$4.(CoreComponentRequestContext.java:161)
org.jboss.portal.core.command.CoreComponentRequestContext.(CoreComponentRequestContext.java:155)
and I'm totally stuck because I don't know what might cause this NullpointerException.
thanks a lot for any advice
Johannes
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988954#3988954
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988954
19 years, 4 months
[Design of JBoss jBPM] - Re: Web Console: Context Menus and Navigation
by david.lloyd＠jboss.com
No difference right now. However, I think it might be very reasonable to restrict the "participant" role to limited versions of each view (for example, User View might only contain the task lists, System View could only contain a process list, and Process Definition View might contain only the ability to view summary information and start the process running).
This is easily accomplished by using the standard disabled="#{identityBean.participant}" kind of mechanism on any component that is to be rendered inaccessable to a role. I've left that task as something that can be put off, because it is simpler to do. At some point (soon) I want to be able to say, "this is the functionality that will be in 3.2.0". If roles don't make it in, I see this as less detrimental than if key content is left out.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988952#3988952
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988952
19 years, 4 months