IBM WebSphere Adapters Benutzerhandbuch
During recovery, WebSphere Application Server calls the resource adapter, queries
it for XAResources, and then performs transaction recovery as follows:
it for XAResources, and then performs transaction recovery as follows:
v
Transactions that the J2EE container rolls back have not been delivered and are
marked NEW.
marked NEW.
v
Transactions that the J2EE container commits have been delivered; these are
deleted.
deleted.
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.
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.
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.
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
Field
Description
Event Identifier (ID)
A unique identifier for the event
Object Key
The application-specific data that uniquely
identifies the entity that occasioned the
event.
identifies the entity that occasioned the
event.
Business Object Name
The type of the business object that maps to
the entity.
the entity.
Verb
The operation that triggered this event:
create, update, delete, and so on.
create, update, delete, and so on.
Timestamp
The time at which the application generated
the event.
the event.
Status
The status of the event. This is used by the
Foundation Classes to track which events
are new, in process, or processed.
Foundation Classes to track which events
are new, in process, or processed.
XID
The transaction ID.
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
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