/**\*
** The enumeration of transaction event types
*/
public class TransactionEventType extends SimpleEnumerationType {
 private static final long serialVersionUID = –4218786755116808448L;

private static final List VALUES = new ArrayList (5);

/**\*
** Notification of inserted features, after insertion occurred
* (collection contains newly inserted features)
*/
 public TransactionEventType POST\_INSERT = new TransactionEventType
(“PostInsert”,
 “Features just inserted”);

/**\*
** Notification of updated features, before update occurs 
* (collection contains original values)
*/
 public TransactionEventType PRE\_UPDATE = new TransactionEventType
(“PreUpdate”,
 “Feature values before update”);

/**\*
** Notification of updated features, after update occurs
* (collection contains updated features)
*/
 public TransactionEventType POST\_UPDATE = new TransactionEventType
(“PostUpdate”,
 “Feature values after update”);

/**\*
** Notificaiton of deleted features, before deletion occurs
* (collection contains features that will be deleted)
*/
 public TransactionEventType POST\_DELETE = new TransactionEventType
(“PostDelete”,
 “Features just deleted”);

protected TransactionEventType (String name, String description) {
 super (VALUES, name, description);
 }

public CodeList[] family () {
 synchronized (VALUES) {
 return (TransactionEventType[]) VALUES.toArray (new
TransactionEventType[VALUES.size ()]);
 }
 }
}

/**\*
** Event carrying information about a change that happened/that is about
to
* occur. The feature collection may be an in-memory one, or may be
based
* on a real datastore with a filter.
 **/
public interface TransactionEvent {
 /**\*
* The type of change occurring
*/
 public TransactionEventType getType ();

/**\*
** A collection of the features that are being manipulated. 
*/
 public FeatureCollection getAffectedFeatures ();
}

/**\*
** Implemented by classes needing to listen to datastore change events
* during a WFS Transaction
 **/
public interface TransactionListener {
 /**\*
* Check/alter feature collections and filters before a 
* change hits the datastores
*/
 void dataStoreChange (TransactionEvent event) throws WFSException;
}
```

The TransactionPlugin interface must be implemented by anyone needing to get involved in the trasaction processing and have a way to tell if the transaction need to be aborted, as well as get notified of transaction start and end, allowing for batch handling of changes:

/**
 * A transaction plugin is able to listen to a transaction evolution,
 * perform checks and throw exceptions, alter transaction requests, as 
 * well as 
interface TransactionPlugin extends TransactionListener {
   /**
    * Check/alter the transaction request elements
    */
   TransactionType beforeTransaction(TransactionType request) throws WFSExceptoin;

   /**
    * Say the last word before we actually commit the transaction
    */
   void beforeCommit() throws WFSEXception

   /**
    * Notification the transaction ended
    * @param committed true if the transaction was successful, false if the
    *        transaction was aborted for any reason
    */
   void afterTransaction(boolean committed);

   /**
    * Aspects gets called in a specific order. State your priority, the higher
    * the number, the earlier the plugin will be processed.
    */
   int getPriority();
}

Finally, transaction element handlers need to implement this interface:

/**
 * Returns the qualified names of feature types needed to handle this
 * element
 */
QName[] getTypeNames(EObject element) throws WFSTransactionException;

/**
 * Checks the element content is valid, throws an exception otherwise
 * 
 * `param element

Same as above, depicted as a class diagram:

![image](TransactionFramework.png)

#### Dyamic view

When transaction processing starts the Transaction class will:
* Look up every TransactionListener and TransactionPlugin in the Spring
context, store them in two lists, sort plugin according to priority
* Make plugins process the beforeTransaction () event
* Look up TransactionElementHandler for each transaction element,
making sure each XML element is matched by the most appropriate handler
(using nearest superclass approach)
* Ask each TransactionElementHandler for used feature type names, and
look up the FeatureTypeInfo
* Ask each TransactionElementHandler to check its validity
* Lookup the feature stores needed to process the transaction
* Check lock authorizations
* Have each element do its own processing. A single multiplexing
transaction linstender is provided to element handlers, and it will take
care of bouncing the event on each transaction linstener and plugin.
* If all goes fine, notify plugins we’re about to commit
* Commit
* Notify plugins the transaction succesfully committed.

In the event of failure, plugins will be notified the transaction did
not complete successfully.

Open issues and observations
----------------------------

Observations:
* Security may be thought as a transaction plugin, but it’s better to
avoid this temptation. Security restrictions may be imposed on the read
side too, either by making some feature types invisible, or by removing
some prorties, or by filtering out data. This is not a transaction
specific issue, but a system wide one dealing with generic data access,
as such, it must be handled at a catalog level (eventually, as wrapper
or as a plugin of catalog handling).

Risks
-----

This is a significant change in transaction processing, as such it may
introduce bugs. WFS 1.0 and WFS 1.1 CITE tests will mitigate this risk.

Participants
------------

Andrea Aime