July 2007 - jboss-dev-forums - Jboss List Archives

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-4574 and JBAS-1476

by bstansberry＠jboss.com

"adrian(a)jboss.org" wrote : "bstansberry(a)jboss.com" wrote : | | [OT] Re: 'the "view change" is less than it previously was" after a cluster restart. No. The viewId passed between the server and HA clients is not a counter. It is a hash of the service's cluster topology. | | Nice fix. You just broke all the old clients that assume its a counter. What fix? I never changed anything; this is the way viewId has worked in any clustering code I've looked at. I have no idea where this counter concept you have comes from; maybe some early version. It's not the way it works at least since 4.0.3 (and I didn't touch it there). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067095#4067095 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067095

18 years, 8 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-4574 and JBAS-1476

by adrian＠jboss.org

"bstansberry(a)jboss.com" wrote : | [OT] Re: 'the "view change" is less than it previously was" after a cluster restart. No. The viewId passed between the server and HA clients is not a counter. It is a hash of the service's cluster topology. Nice fix. You just broke all the old clients that assume its a counter. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067080#4067080 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067080

18 years, 8 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-4574 and JBAS-1476

by adrian＠jboss.org

Brian's comment just confirms to me that the problem is still not understood, making JIRA issues to fix "random stuff" premature. When you know why JNP/RMI works (assuming it really does, it sounds like it shouldn't? :-) and JNP/HARMI doesn't work, then you'll know what the fix is. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067078#4067078 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067078

18 years, 8 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: Allow setAutoCommit(false) on managed connections

by bill.burke＠jboss.com

I don't think you are listening to me. connection.commit() /rollback()SHOULD fail as it is a state change. setAutoCommit(false) should succeed as there is no state change to the connection if auto commit is already false. Thirdparty code may not be doing commit(), rollback(), but may only be doing setAutoCommit(false). Which should be perfectly fine, again, because there is no state change to the connection. This could be what the user is running into. I don't know. Weston/myself had similar spec religiousness debates with Mark Little around allowing multiple non-XA resources in a transaction. Morale of the story? You may know something is wrong and not the right way to do it, but there may be no other way because you don't control all the variables. Anyways, since I am not coding any of this, doesn't really matter what I think.... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067069#4067069 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067069

18 years, 8 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-4574 and JBAS-1476

by ben.wang＠jboss.com

Basically, this is most of it. We will also need to fix the retry interceptor logic to flush out the cached server info such that a subsquent jndi look up will succeed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067053#4067053 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067053

18 years, 8 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: Allow setAutoCommit(false) on managed connections

by adrian＠jboss.org

"bill.burke(a)jboss.com" wrote : Adrian, you're sounding too much like Mark Little | That's a complement :-) anonymous wrote : | setAutomCommit(false); does not change the transactional characteristics of the connection because autoCommit is already false. We're not talking about the state of the connection, we're talking about when the commit occurs. Is it, where my code assumes it is in the example I posted above or is in the JTA transaction demarcation after the method ends (breaking my code!). By breaking my code, I mean I start another transaction on the connection or I do something else that requires the transaction committed succesfully. | The problem the user is having is that he wants to invoke thirdparty code that he cannot control, with a JTA/JCA managed connection within a transaction. | This is broken. I'm not going to break other people's code to make this work (or more likely lead them to make the same mistakes). It will also lead to non-portable code. Other appservers won't run it. If you want to introduce a ManagedConnectionFactory property that does | setIgnoreAutoCommitInManagedConnection(true); | then go ahead. But it needs to be false by default and come with a big health warning about setting it to true. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067033#4067033 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067033

18 years, 8 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: Allow setAutoCommit(false) on managed connections

by bill.burke＠jboss.com

Adrian, you're sounding too much like Mark Little. setAutomCommit(false); does not change the transactional characteristics of the connection because autoCommit is already false. There is no state change with the call. Since there is no state change, then no error should be thrown. So you can ignore a setAutoCommit(false) with no repurcutions. The problem the user is having is that he wants to invoke thirdparty code that he cannot control, with a JTA/JCA managed connection within a transaction. Because of your interpretation of the spec, he cannot do this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067017#4067017 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067017

18 years, 8 months

1
0
0 / 0

[Design of JBoss Wiki] - Re: Portal 2.6 support...

by indyJones

Hate to keep asking....but is there a eta on the 2.6 wiki? I got some users that keep bugging me about it... :) Thanks Indy View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066990#4066990 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066990

18 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Annotation features

by alesj

"alesj" wrote : How to trigger all those checks from MetaDataVisitorNode.[initial|describe]Visit? | Solved by new wrapper around MetaDataVisitor. ;-) We'll see if the final solution is OK. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066975#4066975 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066975

18 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Annotation features

by alesj

How to trigger all those checks from MetaDataVisitorNode.[initial|describe]Visit? e.g. when I run into @Inject annotation, I add an AbstractInjectionValueMetaData to BeanMetaData (if that property is not already defined ...), but I'm missing all those checks previously done - from setting the context ref, adding dependencies, ... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066940#4066940 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066940

18 years, 8 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 July 2007