| | >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.
Java GC generally takes more than 1 millisecond from start to finish, was my point. This goes even if it is incremental: the GC'ing of the single object, or dozens of objects might go very fast, but the time it takes from start to finish (where the "adress" again is available) would "most probably" take more than a milli. In addition, it would have to be -a LoggingEvent object- that was produced with this specific address for a collision to happen. | | 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) The birthday paradox does not apply here, as I've understood it. Remember the within-a-millisecond criteria, the no-two-"persons"-can-have-the-same-birthday-while-within-one "garbage generation" criteria, and add on to that the from the same logger criteria, the same level criteria, and possibly also with the same message criteria. You're rather far from the birtday paradox now, I feel. But still, it -could- happen. It just seems rather unlikely. Look up a couple of UUID/GUID algorithms. This is actually what you're after, isn't it? Preferrably w/o synchronization hits. Endre. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
