On Dec 27, 2004, at 3:59 PM, Ceki G�lc� wrote: (Switching order of comments)
>What do you mean by "the value of sequenceCount may be slightly out of sync on different threads"?
http://java.sun.com/docs/books/vmspec/2nd-edition/html/ Concepts.doc.html#33308 (toward the end)
http://java.sun.com/docs/books/vmspec/2nd-edition/html/ Threads.doc.html#21294
The pertinent quotes are:
In the absence of explicit synchronization, an implementation is free to update the main memory in an order that may be surprising. Therefore, the programmer who prefers to avoid surprises should use explicit synchronization.
Best practice is that if a variable is ever to be assigned by one thread and used or assigned by another, then all accesses to that variable should be enclosed in synchronized methods or synchronized statements.
Also, Item 48 of Effective Java (Synchronize access to shared mutable data) uses an example which appears to be almost exactly the scenario in LoggingEvent and goes to great length why the code may not perform as expected. Basically each thread is free to maintain its own copy of sequenceCount and is only required to synchronize its values at thread synchronization.
The sequenceNumber+timestamp combination makes it easy to implement equals() method for LoggingEvent.
The implementation might be easy, but appears problematic. The default implementation of equals and getHashCode would be preferred if all you cared about was object identity. If you really care about value equality, you are saying that only the class type, timestamp and sequence number are significant. I could abuse the current implementation of equals by creating a LoggingEvent, cloning it (which could be done using serialization if need be) and changing the level and message of the clone, original.equals(clone) would still return true since the timestamp and sequence number are still identical.
Also, without the synchronization issue on sequenceCount resolved, totally unrelated logging events from different threads may compare equal since they might have the same timestamp and sequence number.
Is there a particular need to implement value comparison of logging events? There don't appear to be any unit tests that depend on it. Deleting the equals and getHashCode implementation didn't make any test cases fail. The coverage analysis indicated that LoggingEvent.equals was called 300386 times, but every one returned true since (this == rObject) was true, but I didn't track down where LoggingEvent.equals was called.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
