IBM WebSphere Adapters User Manual page 88

During recovery, WebSphere Application Server calls the resource adapter, queries
it for XAResources, and then performs transaction recovery as follows:
v Transactions that the J2EE container rolls back have not been delivered and are
v Transactions that the J2EE container commits have been delivered; these are
Implementing an event store in the EIS
An event store is a persistent storage area in the EIS application where event
records are saved until the adapter can process them. The event store might be a
database table, application event queue, email inbox, or any type of persistent
store. A persistent event store enables the application to detect and save event
records for the adapter even when the adapter is not operational.
Note: Always consider performance implications and scalability when choosing
where and how to implement an event store. For example, if you are building an
adapter for a database application, an event store represented as a table in the
database will most likely perform more efficiently than an event store implemented
in an external event inbox.
Event records:
There are no hard and fast rules governing the structure or content of an event
record in the event store. The goal is to provide enough information for the
EventStore interface implementation to successfully generate a business object that
represents the event.
Common event record fields
Event Identifier (ID)
Each event requires a unique identifier for tracking purposes. This identifier can be
a number generated by the application or a number generated by a scheme that
your adapter uses. The event might generate a sequential identifier, such as 00123,
to which the adapter adds its name. In such an event ID numbering scheme, the
resulting object event ID is MyAdapterName_00123. Another technique might
82
WebSphere Adapters: WebSphere Adapter Toolkit User Guide
marked NEW.
deleted.
Field
Event Identifier (ID)
Object Key
Business Object Name
Verb
Timestamp
Status
XID
Description
A unique identifier for the event
The application-specific data that uniquely
identifies the entity that occasioned the
event.
The type of the business object that maps to
the entity.
The operation that triggered this event:
create, update, delete, and so on.
The time at which the application generated
the event.
The status of the event. This is used by the
Foundation Classes to track which events
are new, in process, or processed.
The transaction ID.