This one time, at band camp, Stephen Ince said:
SI>I have attached a performance fix for castor using jdk1.3.1. The
SI>org.exolab.castor.persist.TransactionContext was using a Vector to store
SI>objects. The instance variable _objects is now of type
SI>org.apache.turbine.util.SequencedHashtable. The objects can be retreived in
SI>order and removed using hashtable lookups. It is was a significant
SI>performance improvement for me.
Steve,
First, please read through the Guidelines for Code Contribution:
http://www.castor.org/cvs.html#Guidelines-For-Code-Contribution
Second, create a Bugzilla (http://bugzilla.exolab.org/) report for this
with a severity of Enhancement and attach the diff to this report. Please
make sure you provide information about the dependencies that this
introduces.
I have been considering the use of some other things that require the
Jakarta Commons Collections package so I'm curious to know if the same
result could be achieved using the SequencedHashMap:
http://jakarta.apache.org/commons/collections/api/org/apache/commons/collections/SequencedHashMap.html
The disadvantage I see are that the SequencedHashtable is threadsafe
whereas the SequencedHashMap is not.
I don't want to include the entire Turbine jar just to make use of
one class within it. Also, the Turbine jar is 749k! The only jar that
The Castor Project redistributes that in the neighborhood of that size
is Xerces.
Bruce
--
perl -e 'print unpack("u30","<0G)[EMAIL PROTECTED]&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://incubator.apache.org/projects/geronimo.html
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
