> No one has commented on the idea of using sequential ids to > distinguish > between logging events.
I think this is an incredibly important feature, and one probably lacking in the internals of the LoggingEvent class at the moment too (irrespective of a unique id in the dB).
Doesn't the JDK1.4 logging framework assign something of a 'unique' id to each event instance? Is this something we should consider for log4j, as this would add a fair bit of power to the aggregation of events from different sources.
Hi Paul,
The way JDK 1.4 does it is not necessarily a good approach. See below.
Not sure of any performance penalty though of having to generate an id with each LoggingEvent instance construction.
JDK 1.4 logging events generate auto-incrementing ids starting at zero. Thus, the generated ids are not unique across JVM instances. Although the combination of the auto-incrementing id and the time of event generation could provide a semblance of uniqueness and hence tested for in the LoggingEvent.equals() method. Scott, what do you think?
One way to achieve uniqueness across JVM instances is by marking each event by a combination of 1) an auto incrementing id, 2) ip address of the host 3) start time of the JVM. This combination would guarantee uniqueness with high degree of security across JVMs. If one is concerned about uniqueness, than the solution described in the previous paragraph should be sufficient for most purposes.
However, in the case of a database table storing events from different sources, we require uniqueness *and* sequential ordering. One property without the other is not that useful.
A sequential primary key generated by the database will ensure uniqueness and sequential ordering within the database. However, a primary key is semantically quite different than the auto-incrementing id used in JDK 1.4. The primary key is controlled by the database and can be null at the time a logging event is generated whereas the id generated by the JDK can never be null.
In summary, we've got a solution for implementing equals in a fast and robust fashion. Sequential ordering still quires the services of a cooperative database engine.
cheers,
Paul Smith
-- Ceki G�lc�
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]
