logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject RE: PreparedStatementAppender vs. JDBCAppenderPlus
Date Wed, 28 Apr 2004 10:02:01 GMT
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 

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.

>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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message