Browse Prior Art Database

Lazy Population of Event Record Data (AEC) Disclosure Number: IPCOM000020580D
Original Publication Date: 2003-Nov-28
Included in the Prior Art Database: 2003-Nov-28
Document File: 3 page(s) / 78K

Publishing Venue



This article describes the design for an event infrastructure API which reduces the overhead of events that are deactivated

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 54% of the total text.

Page 1 of 3

Lazy Population of Event Record Data (AEC)

There are a number of existing infrastructures for managing events (product trace, Tivoli* TEC). These event infrastructures are used to record information typically about error situations (for example, writing error messages or trace data). Events themselves are a collection of properties describing the situation and the environment in which it occured. Often, events can be activated and deactivated based on some configuration. Since events can be produced in the mainline path it is important that the overhead of having an event in an application is kept to a minimum (especially when the event is deactivated).

    Typically, the control for activating and deactivating an event is based on data that is external to the event. So, for example, in an application server such as Websphere * Application Server or CICS*, the trace is activated and deactivated based on the server component that is writing the trace. To avoid having to build the trace event when trace is deactivated, the component tests a flag to discover whether its trace is active and only builds the trace record if it is:

if (my trace flag is active) {

build and log trace event }

    For some programming languages this code can be collapsed into a single macro call. However, this is not possible in Java* and so the Java code is either littered with these "if" statements, or the test occurs in the trace component after the trace event has been created.

    The solution presented here relates to business events. This is a new type of event where a lot of the issues are similar to the existing event infrastructures but there are some additional requirements:

The business event can contain properties that are large and expensive to build. Therefore these properties should not be built unless the event is active. The control logic that determines whether the event is active or deactivated is defined externally to the application and is defined in terms of the properties inside the event. The application does not know which properties they are. The event is typically routed to a remote server to be stored centrally. The events will appear all over the application and should be simple to code. We need to keep the code that the application has to write to a minimum.

    An interface is provided that has a single method for generating events. Behind this interface, the server checks whether the event should be created and only when event is required is the code to format the "expensive" properties called. The code for the "expensive" properties is supplied to the server as a callback object.

    When an application wishes to generate an event, it calls the event factory to create an event object. The application then sets the properties for the event into the event object. It may also pass an "additional properties" object into the event object. This contains enough data to format the expensive properties.