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]
<<winmail.dat>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
