AUTO_INCREMENT is a feature supported by many databases so the nomenclature used in my previous mail was a little confusing. Let me attempt to correct this now.
We currently have the timestamp field in LoggingEvent. This timestamp is of type "long" which measures the number of milliseconds elapsed since 1.1.1970 00:00 GMT and the time the logging event was created. Since the timestamp is measured in milliseconds, this field alone is not sufficient in determining the equality of two logging events even when generated from within the same JVM. (More than one event could be generated within the same millisecond.)
The addition of another field called "counter" could helps us to resolve the equality problem. The counter field would be incremented by one for each newly generated event. LoggingEvent instances would carry the value of the counter. This is what I referred to as the auto-incrementing id.
The timestamp and counter also help ordering the events. Event e0 precedes event e1 if its timestamp value of e0 is smaller than the timestamp value of e1. If both timestamp values are equal, then e0 precedes e1 if its counter value is smaller than that of e1. If both the timestamp and the counter values are equal then the two events are equal.
If we need to take into account ordering for multiple processes on different machines, then the timestamps are not sufficient in case the clocks of the various machines are not perfectly synchronized. A simple approach is to have the insertion into the database determines the order. As Scott mentioned, insertion into the database may not perfectly reflect the real ordering of events. However, assuming the various process experience similar latencies when accessing the database, then order of insertion should closely approximate the actual ordering of events. Basically, this approach uses a centralized system, the database, which we need anyhow, to order events. There is no performance cost to this approach and it should be simple to implement...
At 04:34 PM 4/28/2004, Scott Deboy wrote:
What is the goal? Tracking the ordering of events across processes?
I'm not sure an auto-incrementing ID added to the table will solve this problem 100%. It should be accurate most of the time. Maybe that's sufficient.
An auto-incrementing ID will ensure we can discover the sequencing of events from a single appender, but to support ordering between sources, do we need serialized transactions and a single process in the environment that actually writes the events to the database?
Say process A generates a logging event and sends a message to process B. When process B receives the message, it also generates a logging event.
Can we be sure that process A's event will have been written to the database prior to process B's event?
Is this a case where relying on EJBs or JMS makes sense?
Scott
-----Original Message----- From: Ceki G�lc� [mailto:[EMAIL PROTECTED] Sent: Wed 4/28/2004 3:02 AM To: Log4J Developers List Cc: Subject: RE: PreparedStatementAppender vs. JDBCAppenderPlus At 12:54 AM 4/28/2004, Paul Smith wrote: > > 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- 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]
