November 2006 - jboss-dev-forums - Jboss List Archives

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

by mark.little＠jboss.com

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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989370#3989370 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989370

19 years, 4 months

1
0
0 / 0

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

by weston.price＠jboss.com

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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989366#3989366 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989366

19 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: Zero turnaround Java/JBoss

by bill.burke＠jboss.com

"sacha.labourey(a)jboss.com" wrote : Concerning the "clean redeploy" of classes, instead of relying on facing hotswap behaviour or similar, why not use a simpler approach where we would load the NEW classes in a new Classloading tree and start routing new requests to that classes tree once it has been properly loaded? This idea only addresses the use case where zero "metadata-sources" have changed on disk. By a metadata-source I mean an ejb-jar.xml file, a bean class, or a business interface. If a metadata-source changes, you're gonna have to be real careful on how changes are merged with the old metadata. anonymous wrote : | The trick is to make sure that the SAME "containers" and services are able to work on multiple classes trees (and, for example, keep a single version of a cache, or a lock table, of a transaction table, etc. => services and containers would rely on specific ID, not on specific class instances) | | That way, if you have a long running requests being processed, this request can continue in parallel with new requests. The old request would keep using the old classes definition while new requests could use the new class definitions. | | That could also speed up app re-deployment A LOT: there wouldn't be this huge gap anymore between the undeploy of version 1 and the total redeploy of version 2: instead, any requests would be able to keep using version 1 while we fully load version 2 and at that time, we can do a micro-switch that would route any incomnig request to the new class tree. This could certainly be easily handled by using the per-container/per-request METADATA i.e. the class tree to use would be specified in the METADATA and used dynamically at runtime by the containers/services. | | That means we could also support, in a more "production" kind of environment, stable "switch of releases" i.e. JBoss ON could distribute a new version of an application to 50 nodes of a cluster, PREPARE the application by loading it in a new class tree and, once all nodes have successfuly loaded the new tree, you atomically re-route all new requests to this new app => standby mode for pre-loaded apps. This scenario is probably slightly more complex as it would probaly require a change in metadata, hence is possibly a different scenario. You're talking more about applications in production, while this thread is focused more on zero turnaround in development. For this case, it doesn't matter much on how fast the creation of the new metadata (or container) is, just that the swap from the old version to the new is superfast and seemless to the application. What this thread is discussing is getting closer to the zero turnaround time of Rails in development so that Java EE/JBoss can be used in RAD environments more viably and closer to the productivity that Rails brags about (and so that people don't use gay scripting language to do development). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989358#3989358 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989358

19 years, 4 months

1
0
0 / 0

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

by mark.little＠jboss.com

"bill.burke(a)jboss.com" wrote : Furthermore, it is completely idiotic and gay to develop a new and different interface other than JTA if I want to use two non-XA enabled resources in the same unit of work. JTA is a great abstraction and has very tight integration with things like EJB to make your life tons easier. The abstraction JTA gives is based on ACID transactions. You are proposing to break that abstraction. XAResources are the two-phase participants that can be enlisted in the transaction. Yes, I know you know this, but we're having a discussion here so it's worth pointing this out. Basically you are suggesting that we allow arbitrary enlistment of non-two phase aware XAResources within a transaction and break the protocol. I think that doing that within JTA is "idiotic and gay". Furthermore, at the moment all of this is academic as far as I am aware. We have no customers who need this. If some come forward, then we can look at the issue, assuming their scenarios cannot be addressed through some other way. anonymous wrote : | BTW, you're the same guy who tried to argue with me that JTA is useless when you have only one resource in your transaction. | Sorry, not me. Any good JTA implementation covers the 1-resource optimisation, so you don't get the overhead of 2PC. If I said anything it was probably that any good JTA implementation doesn't have to do a lot in this case. anonymous wrote : | Anyways, there is absolutely nothing wrong with using multiple non-XA resources in same TX if a) you can't make them all XA and/or b) more importantly, you are aware of the consequences. | On that we can agree. They MUST be aware of the consequences. anonymous wrote : Forcing users ,for the sake of purity, to refactor their applications when they are aware the problem exists is just plain pompus. | 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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989355#3989355 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989355

19 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Usage of OID on ConnectionFactories

by clebert.suconic＠jboss.com

The objectID is a sequence generated ID. The JNDI name is unique for a connection factory. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989353#3989353 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989353

19 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: Microcontainer and JBossXB

by scott.stark＠jboss.org

Ok, this is my fault. Of the snapshots: | <componentref name="jboss/common" version="snapshot"/> | <componentref name="jboss/jbossxb" version="snapshot"/> | <componentref name="jboss/test" version="snapshot"/> | <componentref name="jboss/test14" version="snapshot"/> | we should move the mc trunk dependencies for all but jbossxb to those from the jbossas beta: | <componentref name="jboss/common-core" version="2.0.2.GA"/> | <componentref name="jboss/common-logging-log4j" version="2.0.2.GA"/> | <componentref name="jboss/common-logging-jdk" version="2.0.2.GA"/> | <componentref name="jboss/common-logging-spi" version="2.0.2.GA"/> | <componentref name="jboss/test" version="1.0.0.GA"/> | <componentref name="jboss/test14" version="1.0.0.GA"/> | I don't even know what the jboss/common snapshot is. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989351#3989351 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989351

19 years, 4 months

1
0
0 / 0

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

by mark.little＠jboss.com

"bill.burke(a)jboss.com" wrote : "mark.little(a)jboss.com" wrote : "bill.burke(a)jboss.com" wrote : +1 for Weston. | | | | | | Mark, why are you being so religious and academic. Weston states all valid cases for the feature. Transactions/unit of work is still extremely useful even without 2pc. | | | | Bill, this is not academic. Multiple one-phase resources in a two-phase transaction does not give you the consistency and atomicity guarantees. When you don't support recovery then it really doesn't make a difference. But when you do, it is wrong to support this and give the impression that this is a valid approach. This is not a transaction (where the definition of transaction is JTA, JTS/OTS, XA, WS-T ACID transaction). If we want to support this, then we should be doing so through some other interface, which makes it clear that the failure and recovery semantics are different. | | Listen, you don't have to spew shit I already know... | | And we should stop spewing shit like 'transactions without recovery are great and useful' when they're not. They are dangerous if people don't understand the full implications of what's not happening for them. anonymous wrote : | I agree with you, but, as you see from Weston's post, it is not always possible to have an XA enabled resource. Things just don't fit into nice little boxes all the time and sometimes developers have to break the rules. | Yeah, but sometimes if they are told what the implications are then they'll find a better route. anonymous wrote : | We used to spew out a warning message when a non-xa resource was being used in a two-phase transaction (not sure if we still do). JBossTM does. JBossTS supports LRCO so it doesn't have to. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989347#3989347 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989347

19 years, 4 months

1
0
0 / 0

[Design of JBoss Portal] - Re: LDAP Support expectations

by bdaw

anonymous wrote : http://jira.jboss.com/jira/browse/JBPORTAL-464 this should be rather "patch" then "feature request. It contains ldap (MSAD) identity modules someone did for 2.2. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989343#3989343 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989343

19 years, 4 months

1
0
0 / 0

[Design of JBoss Portal] - Re: LDAP Support expectations

by bdaw

anonymous wrote : he raodmap shows the first alpha release for 2.6 on 29/Dec/06. Do you think, a testing version is available earlier? We`ll have a workshop next week with a competitor in portal software and it would be good to have testcase on jboss, to see the differences. I cannot give you the eta. I'm doing some additional work on configuration at the moment. Implementation should't take long but some other changes need to be applied to the portal code when switching the implementations. If you want to look at implementation that is present you can check at org.jboss.portal.test.identity.ldap package where test cases are stored. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989340#3989340 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989340

19 years, 4 months

1
0
0 / 0

[Design of JBossCache] - Re: EvictionPolicy methods

by manik.surtani＠jboss.com

+1. I presume these are legacy method calls that have fallen into disuse? Ben, care to comment/confirm? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989332#3989332 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989332

19 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums November 2006