At 05:00 PM 1/11/2005, Endre St�lsvik wrote:
Curt, good points!
On Mon, 10 Jan 2005, Curt Arnold wrote:
| | > When logging an event, we should not build two objects | > (LoggingEventBuilder+LoggingEvent) instead of the current one | > (LoggingEvent). | > | | In that high volume use and reentrant code, it might be best to | continue to use a special constructor, but that might be made package | private so it can only be used within log4j.
I don't see the reason for this: String has both a constructor, and a Builder. Why couldn't LoggingEvent also have this? I do agree with Ceki here - two objects should most definately not be needed when simply wanting to make a new LoggingEvent object. But if you -have- to do it incrementally, then a utiltiy-style Builder is nice. Another approach is of course simply to set temp variables (its only four, isn't it?), and finally, when you actually want to instantiate the LoggingEvent, then do so with the variables - the Builder is really very very simple.
I doubt the builder can be "very very simple" because the LoggingEvent class contains a dozen fields, and its instances can be persisted and later read back. Internally log4j components do not see any difference between an event created 1 nanosecond ago and one persisted 3 months ago and just recently de-serialized. The job of LoggingEvent class is to mask the differences in its life cycle. Its not such a trivial class.
Rip away all the setters, incl. the private ones, make it totally immutable (it's just a immutable "value object"), letting it have -one- constructor taking all the arguments, take away all synch penalties on construction, and optionally also make a utility Builder. Nice.
The possibility for reusing all System.hashCodes within one millisecond seems to me -extremely- close to zero: To have this happen, one would need GC inbetween the instantiations, and having GC take -under- one millisecond, in addition to hitting the same "address" on the two instantiations, just seems plainly impossible.
I have no idea about the algorithm Java uses to allocate memory. The probability of hitting the same address between allocations could be non negligible maybe even quite high. Consider the sequence:
- allocate logging event 1 - allocate logging event 2 ... - allocate logging event N - garbage collect logging events 1, 2, .. N - allocate logging event N+1 - allocate logging event N+2 ... - allocate logging event N+M
...
All this can easily happen in the space of 1 millisecond.
Who can guarantee that no two events in a group of N+M events will not have the same address? After all, the probability of any two persons having the same birthday in a randomly chosen group of 23 persons is higher than 50%. Yes, there are 365+1 possible birth dates but only a few people are needed to produce a collision. (The Birthday Paradox)
Endre
-- Ceki G�lc�
The complete log4j manual: http://www.qos.ch/log4j/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
