Websphere Scheduler is using scheduler datasource XA driver . When task is executed by scheduler it is starting a global transaction, but in our application we are creating a new connection to another database and explicitly commiting the data and closing the connection. This data source configured using non-XA driver datasource. For the application we have also enabled the Accept heuristic hazard (Last participant support extension) .
Now while running the scheudler we are getting the exception DSRA9350E: Operation Connection.commit is not allowed during a global transaction .
Can any one help me out in this
Your task runs in a transaction and probably you call commit in that transaction. So you should call your db operations, commit and close db outside that transaction.
Create bean-managed transaction session bean
#TransactionManagement(TransactionManagementType.BEAN)
and move db and transaction related code into the new bean.
Related
Is there a way to control database connection release strategy in Spring Boot? Something like Hibernate's ConnectionReleaseMode?
My test code would be rougly following:
INSERT query
HTTP call
UPDATE query
INSERT and UPDATE queries are their own methods in a repository bean (either extending CrudRepository, or as a Mybatis #Mapper). HTTP call is in it's own bean.
Now my service bean is where I experiment with different #Transactional settings as my ultimate goal is to have these three steps executed within a single transaction.
The problem is, the HTTP call can take hundreds of millis and Spring is holding the database connection during that time. This quickly leads to an empty connection pool, while the connections themselves are idle.
I have done the same experiments with default configuration using spring-boot-starter-data-jpa and also using mybatis-spring-boot-starter.
The only thing which got me closer to my goal was setting spring.jpa.open-in-view=false for data-jpa, which would release db connections in case of not using #Transactional at all or with propagation set to NEVER. It doesn't work if it's all wrapped in a transactin though.
I'm feeling like I'm missing some vital part of the transaction concept in Spring. Though the Spring reference docs mentions release mode only in relation to JTA transaction manager + JEE container + Hibernate.
Transactions are bound to a connection/session so you can't release the connection in the middle of a transaction. You have to finish the transaction to close/release the connection. Keep in mind that a transaction could abort at any time, and since the HTTP call is not "part of" the transaction, but just runs while the transaction is in progress, it won't help you to keep the transaction open while the HTTP call is running. I'd suggest you go with one of the following solutions:
Use a circuit breaker to cancel the HTTP call if it hits a timeout to have an upper bound for how long a connection/transaction can be open/held
Move the HTTP call out of the transaction, either before or after the transaction
Use two database transactions
Note that you could use a transactional Job Scheduler to schedule a job in the first TX. The job could then, with at least once semantics, try to invoke the HTTP call and then continue with the second transaction or do some compensation if something fails.
We use jBPM 7.41 business application with Oracle database. Under high load, transaction timeouts are detected and arjuna marks them for rollback. Then, jBPM executor thread reuse the same transaction and throws a repetitive exception "No active transaction...". The jBPM is working at the begining but after few minutes of work, there is no active JTA transaction. We use asynchronous executor with a simple command throwing exception, the processes execute normally but as soon as Arjuna Transaction Reaper cancels a transaction, the executor threads will throw the same exception "Explicitly joining a JTA transaction requires a JTA transaction".
We think that the same fix done for JtaTransactionManager in is needed for KieSpringTransactionManager.
We created a ticket here https://issues.redhat.com/browse/JBPM-9450 describing the problem and attached logs and a project to be able to reproduce it.
We tried several options, replacing Narayana with Atomikos and Bitronix, Oracle with PostgreSQL but the issue is the same.
It seems that we’re encountering the same problem described here: https://issues.redhat.com/plugins/servlet/mobile#issue/RHBPMS-4621.
Thank you in advance,
We use:
Spring Boot: 2.2.2.RELEASE
Kie Server: 7.45.0.Final
Narayana: 5.9.0.Final
Logs : https://issues.redhat.com/secure/attachment/12501068/logs.txt
Sample project to reproduce the issue available here: https://issues.redhat.com/secure/attachment/12501190/jbpm-perfs-oracle.zip
One other thing I'm finding, is that it appears that Javers is grabbing all of the available Connections out of my connection pool (created via Spring DataSourceBuilder). I'm not using Hibernate/JPA, just straight JDBC via JdbcTemplate and mostly MyBatis for my entity queries.
I've added a logging statement to my ConnectionProvider for Javers, and at the start of the application when it queries for the schema, it pulls 4 connections to check for each of the tables, and then never returns any of them even after the commit from the PlatformTransactionManager.
I understand from https://stackoverflow.com/a/35147884/570291 that it's supposed to participate in the same connection as the current Transaction. Since I'm not using Hibernate/JPA, does that mean I need to implement the connection tracking/etc from MyBatis to the Javers ConnectionProvider to return the same connection (if there is one), and then handle closing (returning to the pool) of that connection at the end of the transaction?
I found DataSourceUtils.getConnection(DataSource) which is a Spring utility class to get a connection from the given DataSource including if it's tied to a current transaction or not as appropriate. Using that in the ConnectionProvider looks like it's done the trick of keeping the connection for the existing transaction.
JaVers won't return connections to application's connection pool for the same reason as it won't call sql commit or rollback.
Managing connactions and transactions is the application's responsibility, not JaVers. We call it passive mode, from Javers doc:
- JaVers doesn’t create JDBC connections on its own and uses connections provided by an application (via ConnectionProvider.getConnection()).
- JaVers philosophy is to use application’s transactions and never to call SQL commit or rollback commands on its own.
Thanks to this approach, data managed by an application (domain objects) and data managed by JaVers (object snapshots) can be saved to SQL database in one transaction.
In JaVers project there is no mybatis support, so you need to implement ConnectionProvider for mybatis on your own.
Proper implementation of ConnectionProvider shouldn't create new sql connection for every getConnection() call. It should return the connection which underlies current application's transaction. Typically, it's implemented using ThreadLocal.
As you mentioned, ConnectionProvider should handle committing transactions and closing connections.
I have a quartz job that is wired with spring datasource to perform database partition.
I understand setAutoCommit(false) will start a transaction until rollback or commit are called. However I don't know if the transaction will include other queries from spring webservlet by users access the webpage during the quartz partition, from setAutoCommit(false) until setAutoCommit(true)?
So if any servlet query gets error, this would cause rollback to my whole partition transaction.
We have a application, which reads of JMS and does some database transactions, all as part of one XA transaction..
If we find the message has some problems, we want to rollback the database,
but we don’t want the rollback off JMS to have us read the message again(we don't want the MDB to trigger the entire process one more if rollback was previously initiated).
To be sure I understand you correctly: you have a transactional message-driven bean that performs some actions on database. You still want the MDB to be a part of XA transaction, but you don't want the database actions to influence the state of the transaction in which the MDB takes part in.
That being said, there are two solutions:
If the MDB runs within a container-managed transaction, wrap all the database actions into an EJB with #REQUIRES_NEW annotation — unless they're already all run in such transactional context.
If your MDB is bean-managed, the message delivery is NOT a part of transaction, so it will not be redelivered, no matter what — section 5.4.12 of EJB Core Contracts and Requirements:
When a message-driven bean using bean-managed transaction demarcation uses the javax.transaction.
UserTransaction interface to demarcate transactions, the message receipt that causes
the bean to be invoked is not part of the transaction.