Filter
Top Products
When the adapter signals that it has completed delivery, the transaction manager
will then call ″end″, ″prepare″, and ″commit″ to complete the requirements
outlined in the XA transaction protocol. When the ″prepare″ call is made, the XA
implementation will call ″setTransactionID″ on the eventPersistance
implementation; the eventPersistance implementation will store the transaction XID
in the event table. When the ″commit″ call is made, the XA implementation will
call ″updateEventStatus″ on the eventPersistance implementation to set the status
in the event table to ″COMMITED″. This is done for every event that was
retrieved. After all events have been delivered and successfully marked
″COMMITTED″.
When the event is created at the EIS end, configured adapterListener gets notified
and it in turn instantiates CallbackEventSender. Here adapterListener decides
which method to invoke out of the four defined. Lets consider the adapter calls
sendEventWithNoReturn() as shown in the sequence diagram.
Once the program control gets into CallbackEventSender, it checks how many
EndpointFactories are configured for the current instance of adapter. If there is
more than one, then it delivers the event by creating endpoints for each of them
and invoking either onNotification or onMessage method on the endpoint with out
any XA transaction. Finally it would call release() method on the end point to free
the endpoint hence the application server can add it to endpoint pool.
Also it invokes beforeDelivery() and afterDelivery() methods on the endpoint as
defined by the JCA functional specification.
XA transaction will come into picture only when the adapter is configured with
ONE EndpointFactory. The following sequence diagram depicts the callback event
processing for event delivery with XA transaction.
WebSphere Adapter development overview 95