March 2007 - jbosscache-dev - Jboss List Archives

jboss-cache-testsuite-140 Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

17 years, 11 months

1
0
0 / 0

jboss-cache-testsuite-jdk14 build.27 Build Successful

by jboss-qa-internal＠redhat.com

17 years, 11 months

1
0
0 / 0

jboss-cache build.971 Build Successful

by jboss-qa-internal＠redhat.com

17 years, 11 months

1
0
0 / 0

Wiki on BatchModeTransactionManager

by Brian Stansberry

FYI. Manik and I had some discussions about BatchModeTransactionManager last week, and we realized we should somewhat discuss (but not encourage) its use. The AS uses it in web session replication, so it seemed some kind of statement on it was needed. So, a wiki page is born: http://wiki.jboss.org/wiki/Wiki.jsp?page=BatchModeTransactionManager -- Brian Stansberry Lead, AS Clustering JBoss, a division of Red Hat brian.stansberry(a)redhat.com

17 years, 11 months

1
0
0 / 0

Fqns and immutability

by Manik Surtani

Related to the "Fqns-as-strings" discussion, we assume that all Fqns are immutable. I.e., they have no mutators and when we peek() at their elements, we get an immutable collection. But this does not mean that Fqns which are equal point to the same object though. For example, assertSame(Fqn.fromString("/stuff"), Fqn.fromString("/stuff")) fails even though assertEquals(Fqn.fromString("/stuff"), Fqn.fromString("/stuff")) passes. The question to ask is, should the Fqn constructors be made private (or protected), forcing users to use factory methods like Fqn.fromString(String s) and Fqn.fromObjects(Object... objects) and Fqn.fromObjects(Fqn base, Object... objects) so that these factory methods can maintain references to existing Fqns (perhaps in a weak map so they can be gc'd when no longer referenced) and reuse these if possible rather than construction all the time? This was prompted by my running some profiling tests on 2.0.0.BETA1 and found that almost 6% of the time spent (only on a particular test - so not a generic comment) was spent on Fqn construction. And quite often this was the same Fqn. Thoughts? -- Manik Surtani Lead, JBoss Cache JBoss, a division of Red Hat Email: manik(a)jboss.org Telephone: +44 7786 702 706 MSN: manik(a)surtani.org Yahoo/AIM/Skype: maniksurtani

17 years, 11 months

2
2
0 / 0

jboss-cache-testsuite-jdk14 build.26 Build Successful

by jboss-qa-internal＠redhat.com

17 years, 11 months

1
0
0 / 0

jboss-cache-testsuite Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

17 years, 11 months

1
0
0 / 0

jboss-cache-testsuite-140 Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

17 years, 11 months

1
0
0 / 0

jboss-cache build.970 Build Successful

by jboss-qa-internal＠redhat.com

17 years, 11 months

1
0
0 / 0

Mircea's RedcdRecJDBCCacheLoader

by Manik Surtani

Guys, I'm pretty keen on including Mircea's RedcdRecJDBCCacheLoader in 2.0.0: 1) Performance improvement based on removal of recursive DB calls (uses linear calls instead - see Mircea's previous posts) 2) Backward compatible with the existing JDBC cache loader 3) No specific use case why the old JDBCCacheLoader should be used instead of this. So my question to you is this: Do we drop the existing JDBCCacheLoader and rename the RedcdRecJDBCCacheLoader (hate that name!) to JDBCCacheLoader? Comments? -- Manik Surtani Lead, JBoss Cache JBoss, a division of Red Hat Email: manik(a)jboss.org Telephone: +44 7786 702 706 MSN: manik(a)surtani.org Yahoo/AIM/Skype: maniksurtani

17 years, 11 months

3
5
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-dev March 2007