Original title: Spring certified China Education Management Center Apache Geode's spring data tutorial 19 (spring China Education Management Center)
7.5. Use @TransactionalEventListener
When using transactions, you may need to register a listener to perform certain operations before or after the transaction is committed or after a rollback occurs.
Spring Data for Apache Geode makes it easy to create listeners that will@ A specific phase of the transaction annotated by the TransactionalEventListener is called. The annotated method @TransactionalEventListener (as shown below) will be notified of the event published from the transaction method in the specified, phase.
Post transaction commit event listener
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
public void handleAfterCommit(MyEvent event) {
// do something after transaction is committed
}In order to invoke the above method, you must publish an event from the transaction, as follows:
Publish transaction event
@Service
class MyTransactionalService {
@Autowired
private final ApplicationEventPublisher applicationEventPublisher;
@Transactional
public <Return-Type> someTransactionalServiceMethod() {
// Perform business logic interacting with and accessing multiple transactional resources atomically, then...
applicationEventPublisher.publishEvent(new MyApplicationEvent(...));
}
...
}The@ The TransactionalEventListener annotation allows you to specify that the transaction phase will be called in the event handling method. Options include: AFTER_COMMIT，AFTER_COMPLETION，AFTER_ROLLBACK, and BEFORE_COMMIT. If not specified, phase defaults to AFTER_COMMIT. If you want to call the listener even if there is no transaction, you can set fallbackExecution to true.
7.6. Automatic transaction event Publishing
Starting with Spring Data for Apache Geode, Neumann/2.3 can now enable automatic transaction event publishing.
Use@ The EnableGemfireCacheTransactions annotation sets the enableAutoTransactionEventPublishing property to true. The default value is false.
Enable automatic transaction event Publishing
@EnableGemfireCacheTransactions(enableAutoTransactionEventPublishing = true)
class GeodeConfiguration { ... }You can then create a tape@ The POJO method of the TransactionalEventListener annotation to handle the transaction stage AFTER_COMMIT or after_ Transaction events for the rollback transaction phase.
@Component
class TransactionEventListeners {
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
public void handleAfterCommit(TransactionApplicationEvent event) {
...
}
@TransactionalEventListener(phase = TransactionPhase.AFTER_ROLLBACK)
public void handleAfterRollback(TransactionApplicationEvent event) {
...
}
}Only supported TransactionPhase.AFTER_COMMIT and transactionphase AFTER_ ROLLBACK. TransactionPhase.BEFORE_COMMIT is not supported because 1) the SDG adapts the Apache GeodeTransactionListener and TransactionWriter interfaces to implement automatic transaction event publishing, and 2) when the Apache geode TransactionWriter When beforecommit (: transactionevent) is called, it is already in abstractplatformtransactionmanager After the triggerbeforecommit (: transactionstatus) call, @TranactionalEventListener calls the annotated POJO method during the transaction lifecycle.
With automatic transactional event publishing, you do not need to applicationEventPublisher.publishEvent(..) This method is explicitly called in the application @Transactional @Service method.
However, if you still want to receive transaction events "before commit", you must still applicationEventPublisher.publishEvent(..) Call this method in your application @Transactional @Service method.
7.7. Continuous query (CQ)
A powerful feature provided by Apache Geode is continuous query (or CQ).
In short, CQ allows developers to create and register OQL queries, and then automatically receive notifications when new data added to Apache Geode matches query predicates. Spring Data for Apache Geode via org. springframework. data. gemfire. The listener package and its listener container provide special support for CQ; It is very similar to the JMS integration in the Spring Framework in terms of function and naming; In fact, users familiar with JMS support in Spring should feel at home.
Basically, Apache Geode's Spring Data allows methods on POJO s to become CQ endpoints. Simply define the query and indicate which method should be called to receive notification when matching. Apache Geode's Spring Data is responsible for the rest of the work. This is very similar to the message driven bean style of Java EE, but has no requirements for the base class or interface implementation. It is based on Apache Geode.
Currently, continuous queries are only supported in Apache Geode's client / server topology. In addition, the client pool used needs to enable subscription. For more information, see the Apache Geode documentation.
7.7.1. Continuous query listener container
Spring Data for Apache Geode simplifies the creation, registration, lifecycle and dispatch of CQ events by using SDG to handle the infrastructure around CQ, SDGContinuousQueryListenerContainer does all the heavy work on behalf of the user. Users who are familiar with EJB and JMS should find familiar concepts because its design is as close as possible to the support provided in the Spring Framework and its message driven POJO (MDP).
SDGContinuousQueryListenerContainer acts as an event (or message) listener container; It is used to receive events from the registered CQ and call POJOs injected into it. The listener container is responsible for all threads that receive messages and dispatches them to the listener for processing. It acts as an intermediary between EDP (event driven POJO) and event providers, and is responsible for CQ creation and registration (receiving events), resource acquisition and release, exception conversion, etc. This allows you, as an application developer, to write (potentially complex) business logic related to receiving events (and responding to them) and delegate template Apache Geode infrastructure issues to the framework.
The listener container is fully customizable. Developers can choose to use CQ threads to perform dispatch (synchronous delivery) or by defining appropriate java. util. concurrent. A new thread (from an existing pool) of the asynchronous method of the executor (or Spring's TaskExecutor). Depending on the load, the number of listeners, or the runtime environment, the developer should change or adjust the actuator to better meet her needs. Especially in a managed environment (such as an application server), it is strongly recommended to select an appropriate TaskExecutor to utilize its runtime.
7.7.2. Between ContinuousQueryListener and ContinuousQueryListenerAdapter
The The ContinuousQueryListenerAdapter class is the last component that Spring data supports for Apache's Geode CQ. In short, classes allow you to expose almost all implementation classes as EDP S with minimal constraints. The ContinuousQueryListenerAdapter implements the ContinuousQueryListener interface, a simple listener interface similar to Apache Geode's CqListener.
Consider the following interface definitions. Note various event handling methods and their parameters:
public interface EventDelegate {
void handleEvent(CqEvent event);
void handleEvent(Operation baseOp);
void handleEvent(Object key);
void handleEvent(Object key, Object newValue);
void handleEvent(Throwable throwable);
void handleQuery(CqQuery cq);
void handleEvent(CqEvent event, Operation baseOp, byte[] deltaValue);
void handleEvent(CqEvent event, Operation baseOp, Operation queryOp, Object key, Object newValue);
}package example;
class DefaultEventDelegate implements EventDelegate {
// implementation elided for clarity...
}In particular, note that the above implementation of the EventDelegate interface has no Apache Geode dependencies at all. It is indeed a POJO, and we can and will make it EDP with the following configuration.
This class does not need to implement interfaces; An interface is simply used to better demonstrate the decoupling between the contract and the implementation.
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:gfe="https://www.springframework.org/schema/geode"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.springframework.org/schema/beans https://www.springframework.org/schema/beans/spring-beans.xsd
https://www.springframework.org/schema/geode https://www.springframework.org/schema/geode/spring-geode.xsd
">
<gfe:client-cache/>
<gfe:pool subscription-enabled="true">
<gfe:server host="localhost" port="40404"/>
</gfe:pool>
<gfe:cq-listener-container>
<!-- default handle method -->
<gfe:listener ref="listener" query="SELECT * FROM /SomeRegion"/>
<gfe:listener ref="another-listener" query="SELECT * FROM /AnotherRegion" name="myQuery" method="handleQuery"/>
</gfe:cq-listener-container>
<bean id="listener" class="example.DefaultMessageDelegate"/>
<bean id="another-listener" class="example.DefaultMessageDelegate"/>
...
<beans>
The above example shows several different forms that listeners can have; At a minimum, a listener reference and an actual query definition are required. However, you can specify a name for the generated continuous query (for monitoring) and the name of the method (handleEvent by default). The specified method can have various parameter types. The EventDelegate interface lists the allowed types.
The above example uses the Spring Data for Apache Geode namespace to declare an event listener container and automatically register listeners. The complete bean definition is as follows:
<!-- this is the Event Driven POJO (MDP) -->
<bean id="eventListener" class="org.springframework.data.gemfire.listener.adapter.ContinuousQueryListenerAdapter">
<constructor-arg>
<bean class="gemfireexample.DefaultEventDelegate"/>
</constructor-arg>
</bean>
<!-- and this is the event listener container... -->
<bean id="gemfireListenerContainer" class="org.springframework.data.gemfire.listener.ContinuousQueryListenerContainer">
<property name="cache" ref="gemfireCache"/>
<property name="queryListeners">
<!-- set of CQ listeners -->
<set>
<bean class="org.springframework.data.gemfire.listener.ContinuousQueryDefinition" >
<constructor-arg value="SELECT * FROM /SomeRegion" />
<constructor-arg ref="eventListener"/>
</bean>
</set>
</property>
</bean>
Each time an event is received, the adapter automatically performs type conversion transparently between the Apache Geode event and the required method parameters. Any exception caused by a method call is caught and handled by the container (by default, it is logged).