Event Storage 

Use

You use this function to store changes of an entity instance during a transaction.

Features

You use the following component to store events as sent by entity instances:

●     Class: EntityChangedEvent

●     Class: EventCache

●     Event Merge

●     Transaction Manager

Entity Changed Event

You use the object type EntityChangedEvent to store data of the action triggered by an entity service event. One event is stored for each combination of transaction and entity instance in the event cache. This event is represented by the class EntityChangedEvent.

An entity service will notify the event cache if an entity instance is either created, updated, or deleted. If the cache already contains an event for an entity instance from a previous transaction, the data, which has been changed for this action, is sent to the existing event and the data is then merged.

If information about this entity instance is not contained in the cache, the event cache will create a new event and create an entry in the cache for this instance before the data of this action can be stored in the event.

Event Cache

The event class that is referenced by the event cache (class EntityChangedEvent) implements the package interface javax.transacation.Synchronization. The interface is registered with the corresponding transaction if it is created by the event cache (EventCache).

If a transaction was committed or rolled back, each event class will be referenced to the event cache so that it can be removed. The event is sent even if the transaction was rolled back by the J2EE engine. The information about whether the transaction was committed or rolled back has to be provided to the event receiver using the committed flag as part of the event.

This procedure is illustrated in the simplified class diagram below:

You can only implement the event cache as a singleton. So that two actions implemented on an entity instance access different versions of the event cache (EventCache), only one instance of the event cache can exist in one class loader. Since a transaction cannot run on different server nodes, you can use a singleton.

Event Merge

If a CRUD method is implemented, the operation type of the event in EntityChangedEventchanges if an object with the type ValueObjectChangedData is merged into the same event.

Internally, the event cache uses a java.util.Map to maintain all events. The event itself is stored as a value in map; whereas the combination of transaction ID and the entity instance key is used together as the index key. If a single action event of the entity service is sent to the event cache, then this action has to be merged with an event that is already registered in the event cache.

Each change in state of an entity is associated with a modification of the old or new values that are logged together with the event. For example, if you create a new entity instance and then call the update operation, the event will automatically be updated with the new information. The list of old values will stay empty as the instance did not exist before the transaction was started.

In contrast to the structure of a JMS message, the EntityChangedEvent class maintains four possible operation types for an event. If the creation of an entity instance was compensated by deleting the same instance in one transaction, you need the type none to store this information. Here you implement the method mergeChangedData of the EntityChangedEvent class.

Transaction Manager

If the transaction was committed or rolled back, the transaction manager will send a method registering the event as a synchronization object for this transaction. You use the method afterCompletion.

If the transaction was committed or rolled back (indicated by the parameter status), an event will be sent via JMS if the operation type of EntityChangedEvent is either create, update, or delete. In case of type none, no event is sent as there are no changes to the situation before the transaction was started.