Develop Reference

Spring Integration Transaction management using Atomikos

I am thinking to create a Spring Integration Spring Boot application to
1-Poll messages from a DB
2-Do some processing on it
3-Publish messages to EMS Queue
using Atomikos for Transaction management. My question is: If the above configuration will be transactional with all the required JTA configurations done? Also I have read somewhere, if multiple threads are created in Spring Integration,e.g,using a Splitter, then the context won't to transactional. How to overcome this?

If you configure the poller as transactional, the flow will run in a transaction, as long as you don't hand off to another thread (via an ExecutorChannel or QueueChannel channel, for example).
Adding a splitter will not break the transaction boundary as each split will be processed on the same thread.

Spring Integration has different requirements for transactions, to Do so you need to pass a transaction manager in the poller metaData, for example:
#Bean
public PollerMetadata pollerMetadata() throws NamingException {
return Pollers.fixedDelay(Long.valueOf(env.getProperty("poller.interval")))
.transactional(**transactionManager**).get();
}
With
#Autowired
private PlatformTransactionManager **transactionManager**;
And putting :
#InboundChannelAdapter(channel = "jpaInputChannel", poller = #Poller(value = "**pollerMetadata**"))

JPA outbound channel adapter config in Spring Integration Java DSL

I see there is still no JPA high-level support in Spring Integration Java DSL
Example Spring integration DSL for JPA Inbound Channel adapter
But how it is possible to configure JPA outbound channel adapter on low level?
E.g. to create Java DSL config like this in XML
<int-jpa:outbound-channel-adapter id="moduleMessagePersister" channel="inputPersisterChannel" persist-mode="MERGE" entity-manager-factory="entityManagerFactory">
<int-jpa:transactional transaction-manager="transactionManager"/>
</int-jpa:outbound-channel-adapter>

I remember as promised a contribution :-).
Re. <int-jpa:outbound-channel-adapter>:
Any such an XML component is a Consumer Endpoint for the particular MessageHandler.
See the latest changes in the Core project to help users to determine what to use for the Java & Annotation configuration. And therefore for Java DSL as well: https://jira.spring.io/browse/INT-3964
So, for this particular element we have:
<xsd:documentation>
Configures a Consumer Endpoint for the
'org.springframework.integration.jpa.outbound.JpaOutboundGatewayFactoryBean' (one-way)
updating a database using the Java Persistence API (JPA).
</xsd:documentation>
Therefore we have to configure something like
#Bean
public FactoryBean<MessageHandler> jpaMessageHandler() {
JpaOutboundGatewayFactoryBean factoryBean = new JpaOutboundGatewayFactoryBean();
...
factoryBean.setProducesReply(false);
return factoryBean;
}
And use it from the DSL:
#Bean
public IntegrationFlow jpaFlow(MessageHandler jpaMessageHandler) {
...
.handle(jpaMessageHandler)
.get();
}
Let me know what should be documented else!
And yes: we definitely should utilize JPA adapters in the next 1.2 Java DSL version...

What is the java config equivalent to tcp-outbound-gateway?

I have the following spring-integration XML config
<ip:tcp-outbound-gateway id="outboundClient"
request-channel="requestChannel"
reply-channel="string2ObjectChannel"
connection-factory="clientConnectionFactory"
request-timeout="10000"
reply-timeout="10000"/>
How can I write the Java config equivalent of the above?
I thought the equivalent would be
#Bean
public TcpOutboundGateway outboundClient() {
TcpOutboundGateway tcpOutboundGateway = new TcpOutboundGateway();
tcpOutboundGateway.setConnectionFactory(clientConnectionFactory());
tcpOutboundGateway.setRequiresReply(true);
tcpOutboundGateway.setReplyChannel(string2ObjectChannel());
tcpOutboundGateway.setRequestTimeout(10000);
tcpOutboundGateway.setSendTimeout(10000);
return tcpOutboundGateway;
}
But I couldn't find a way to set the request channel.
Any help would be appreciated.
Thank you

Your config looks good, but you should know in addition that any Spring Integration Consumer component consists of two main objects: MessageHandler (TcpOutboundGateway in your case) and EventDrivenConsumer for subscriable input-channel or PollingConsumer if input-channel is Pollable.
So, since you already have the first, handling, part you need another consuming. For this purpose Spring Integration suggests to mark your #Bean with endpoint annotations:
#Bean
#ServiceActivator(inputChannel = "requestChannel")
public TcpOutboundGateway outboundClient() {
See more in the Spring Integration Reference Manual.
However to allow such a annotation process (or any other Spring Integration infrastructure) you have to mark your #Configuration with #EnableIntegration.
Also consider to use Spring Integration Java DSL to have more gain from JavaConfig.

Spring transaction internals

The situation is as follows:
Method1 has four database update methods in it. The Method1 is annotated using the Spring transaction management semantics.
Method2 has a database read method in it and it is invoked after Method1 has finished executing all its database updates. Method2 is also annotated using the Spring transaction semantics.
There's a web request that comes in, the controller intercepts the request and invokes method1 and then method2.
A transaction is wrapped around the web-request as well.
What I am interested in knowing is:
1.How does Spring know to commit the database updates upon a successful transaction? Is there some reference to the Spring implementation that does the transaction management?
2.Since we have a hierarchy of transactions:
Transaction around the web-request->Transaction with Propagation=RequestNew for Method1->Transaction with Propagation=Required for Method2, how does Spring do the transaction management to ensure the transactions are executed within the proper context with the right order?
In short, it will be great to get a play by play account of how Spring performs the transaction management in all its grittiest details or a reference to documentation that doesn't simply hand-wave an explanation centered around JTA or some other acronym.
Thanks

Lets make some basic statements.
A transactional context is an environment where some special properties (database session) are made available to the application runtime which are otherwise not available. A Transaction Context is generally used to scope a transaction.
Spring uses, AOP Proxies and XML metadata to achieve a Declarative transaction management.
Annotations are used to mark the Transaction Propagation behavior of a particular method.
Spring uses Interceptor Mechanism to apply the transaction over the methods.
Here I am reusing the example give by #stacker above
MyClass{
#Transactional
public void sequence() {
method1();
method2();
}
#Transactional
void method1() {
}
#Transactional(propagation=Propagation.REQUIRES_NEW)
void method2() {
}
}
You can also achieve the same functionality using xml configuration as well. Lets take this as its popular and widely used.
At the time of deployment
Spring framework checks the xml configuration files (famed applicationContext.xml) and depending on the configuration, scans the code for #Transactional annotation (assuming that the configuration is mentioned as annotation based).
After this, it generates AOP proxies for methods marked for transaction. In simple terms, these proxies are nothing but wrapper around the concerned methods.
Within these wrapper methods, before and after a Transaction Advisor code is also generated depending on the configuration (namely the transaction propagation).
Now when these wrapper methods are invoked Transaction Advisor comes into picture before and after the actual method call. .
Representing the same in pseudo code for the example above
ProxyMyClass{
MyClass myclass;
.
.
.
sequence(){
//Transaction Advisor code (Typically begin/check for transaction)
myclass.sequence();
//Transaction Advisor code(Typically rollback/commit)
}
.
.
.
}
This is how spring managers the transaction. A slight oversimplification though.
Now to answer your questions,
.How does Spring know to commit the database updates upon a successful transaction? Is there some reference to the Spring implementation that does the transaction management?
Whenever you call a method under transaction, you actually call a proxy which first executes the transaction advisor (which will begin the transaction), then you call the actual business method, once that completes, another transaction advisor executes (which depending on way method returned, will commit or rollback transaction).
Since we have a hierarchy of transactions: Transaction around the web-request->Transaction with Propagation=RequestNew for Method1->Transaction with Propagation=Required for Method2, how does Spring do the transaction management to ensure the transactions are executed within the proper context with the right order?
In case of transaction hierarchy, the spring framework generates the Transaction Advisor checks accordingly. For the example you mentioned,
for method1 (RequestNew ) Transaction Advsor code (or transaction Advice) would be to create a new transaction always.
for method2 (Required ) Transaction Advisor code (or transaction Advice) would be check for existing transaction and use the same if it exists or else create a new transaction.
There is an image on the spring documentation page which very nicely summarizes these aspects.
Hope this helps.

Controller
#Transactional
public void sequence() {
method1();
method2();
}
#Transactional
void method1() {
}
#Transactional(propagation=Propagation.REQUIRES_NEW)
void method2() {
}
The default propagation is REQUIRED (Support a current transaction, create a new one if none exists.) Therefore m1 will use the Transaction started in the Controller. m2 is annotated as REQUIRES_NEW ( Create a new transaction, suspend the current transaction if one exists.) The order of the transaction is the order you call the transactional methods.
Controller
begin tx1
|--------------------> m1 (uses tx1)
|
| begin tx2
|--------------------> m2 (uses tx2)
| commit tx2
commit tx1

Have you read the Spring documentation? Basically AOP is used to manage the transaction. You should also read the AOP documentation. If the AOP documentation is not enough I suggest you go through the code. Stepping through the code in debug mode with break-point would be good.

How to propagate Spring transaction to another thread?

Perhaps, I am doing something wrong, but I can't find a good way out for the following situation.
I would like to unit test a service that uses Spring Batch underneath to execute jobs. The jobs are executed via pre-configured AsyncTaskExecutor in separate threads. In my unit test I would like to:
Create few domain objects and persist them via DAO
Invoke the service method to launch the job
Wait until the job is completed
Use DAO to retrieve domain objects and check their state
Obviously, all above should be executed within one transaction, but unfortunately, transactions are not propagated to new threads (I understand the rationale behind this).
Ideas that came to my mind:
Commit the transaction#1 after step (1). Is not good, as the DB state should be rolled back after the unit test.
Use Isolation.READ_UNCOMMITTED in job configuration. But this requires two different configurations for test and for production.

I think the simplest solution would be configure the JobLauncher with a SyncTaskExecutor during test execution - this way the job is executed in the same thread as the test and shares the transaction.
The task executor configuration can be moved to a separate spring configuration xml file. Have two versions of it - one with SyncTaskExecutor which is used during testing and the other AsyncTaskExecutor that is used for production runs.

Although this is not a true solution to your question, I found it possible to start a new transaction inside a worker thread manually. In some cases this might be sufficient.
Source: Spring programmatic transactions.
Example:
#PersistenceContext
private EntityManager entityManager;
#Autowired
private PlatformTransactionManager txManager;
/* in a worker thread... */
public void run() {
TransactionStatus tx = txManager.getTransaction(new DefaultTransactionDefinition());
try {
entityManager.find(...)
...
entityManager.flush(...)
etc...
txManager.commit(tx);
} catch (RuntimeException e) {
txManager.rollback(tx);
}
}

If you do want separate configurations, I'd recommend templating the isolation policy in your configuration and getting its value out of a property file so that you don't wind up with a divergent set of Spring configs for testing and prod.
But I agree that using the same policy production uses is best. How vast is your fixture data, and how bad would it be to have a setUp() step that blew away and rebuilt your data (maybe from a snapshot, if it's a lot of data) so that you don't have to rely on rollbacks?