Ceki Gülcü wrote:
In my experience, and I have only been doing high volume server apps for about four years now, you can never rely on theory. Always err on the side of caution.
The core of log4j is quite small. So what applies for large pieces of software, does not necessarily apply to the case in hand.
Erring on the side of caution is perfectly reasonable if you do not want to spend the brain cycles to understand the problem in all its details. However, if you have the luxury of thinking about the problem long enough or if the problem is particularly simple, you can come up with an approach that nicely fits the problem.
Also, the ReaderWriterLock is a nice thing in theory, but you need to take a look at what the main purpose of the class is. If it is to be read often, then making it read-only after initialization is the best approach. You only have to synchronize the init code, and you don't have to worry about reading. If the class is mainly volatile (i.e. a lot of writes) then your read/write lock will end up behaving like a Mutex, which is much easier to write and debug.
The category class is often read but seldom modified. Unfortunately it cannot be cloned. So the ReaderWriterLock seems to nicely fit the bill.
As to adding objects to arrays of vectors, then may I remind you that some collections will bork on "null" objects?
Good point. The code in question (in Category class) checks against null objects.
--
Ceki For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
