We are using JPA in our project (using Oracle Database) and also want to use apache JackRabbit API. But If you use a database- persistence manager, the configured database connection must not be under the control of an external transaction manager. Jackrabbit implements distributed XA transaction support on a higher level, and expects to be in full control of the underlying database connection.
What is the solution for this problem?
Related
We have an old EJB based web application which we are supposed to migrate into Spring boot. For database connectivity, it is a plain old jdbc connection approach as of now.
We want to use Spring transactions and remove EJB transactions but willing to keep plain old jdbc connectivity same. In short we don't want to make changes in our DAO layer to convert plain old jdbc to Spring JdbcTemplate.
Please note that we have our own connection pooling algorithm and we create connection object and close it in the pool.
Along with this we want our application to be multi-tenant that can work with multiple databases on the basis of 'tenantID' that we will provide.
I actually tried to implement this but it is not working. I had to manually do con.commit(); and con.rollback();
Is there any way to use Spring transactions with plain old jdbc connectivity with above scenario?
I'd like to add XA connection pool to my Spring based application, specifically Oracle UCP. This pool works on XADataSource and XAConnection objects. Standard DataSource.getConnection(...) methods are not supported.
Trying working with that pool (that I am able to successfully set up in Spring) I am getting an error related to the fact that getConnection(...) methods invoked by JdbcTemplate are disabled and should not be used. I am just wondering whether any of Spring JDBC classes are able to work with XADataSource and XAConnections? Probably there are another ways to use Spring with XA connection pools? Will appreciate any advices on that topic.
Just for those who may experience similar problems - Spring doesn't support directly XA connection pools (through native XADataSource.getXAConnection(...) methods). You need to write a kind of wrapper utilizing DatSource.getConnection(...) methods.
I have an Enterprise Application (ear) deployed in this configuration enviroment:
Weblogic 12c (12.1.1) + Oracle RAC 11g (release 2).
Web Module is an MVC application, implemented with Struts 2 and Spring-framework (3.2.2) for core services. Spring JDBC is used for database access with simple JdbcTemplate for single statements and DatasourceTransactionManager for complex ones. I noticed a strange behavior when I enable Weblogic jdbc logs. When I start a new transaction, I can see jdbc info logs about transaction creation, retriving jdbc connection from weblogic datasource pool and setting autocommit property to false value over connection itself. But I can't see transaction releasing connection log, and restoring autocommit flag to true value after commit/rollback invocation.
It's possible that Spring Transaction Manager does not release jdbc connection and does not restore "autocommit" value flag (to true)? After a while I can see within my application some persistent locks on db tables, causing an overall defect of my application and that I would not have depended on the behavior of the transaction manager.
Has anyone noticed a similar behavior?
Is it possible that jdbc connection is not released by the framework and it can compete in multiple transactions (as seen in jdbc log)?
Thanks
Paolo
Since you are using managed DataSource from WebLogic (JNDI?) you have to use managed TransactionManager as well:
<tx:jta-transaction-manager/>
should be enough:
if (weblogicPresent) {
return WEBLOGIC_JTA_TRANSACTION_MANAGER_CLASS_NAME;
}
And it is instead of that DatasourceTransactionManager.
I am not running under Java EE.
I want to have an XA transaction using Spring to share a transaction between DB and JMS.
Does spring provide such a functionality or must I use an external transaction manager such as Atomikos?
I use currently the DataSourceTransactionManager for the DB, and I see I can also use the JMSTransactionManager. Do they work together? Not clear from the documentation as JtaTransactionManager is mentioned.
Please advise.
Yair
Spring only provides a framework for transaction management, it as such doesn't provide any transaction manager. If you are running your application outside a Java EE container and you need a transaction between resources like a DB and JMS, you have to use an external TransactionManager like Atomikos or JOTM (Java Open Transaction Manager).
You might want to refer to http://www.javaworld.com/javaworld/jw-04-2007/jw-04-xa.html for more details on XA using Spring.
they are resource local, but Spring does support XA (see this post for explanation and example code) : http://blog.springsource.com/2011/08/15/configuring-spring-and-jta-without-full-java-ee/
I'm using Oracle 11g for my database and its Oracle Streams AQ feature as JMS implementation.
For all I know, it should be possible to implement a Spring based message-driven POJO (MDP) that uses the same data source for both transactional data access and JMS transactions -- all without XA-Transactions (IIRC, this was marketed as a feature of SpringSource Advanced Pack for Oracle).
Is this possible using Hibernate as well? Ideally, my MDP would start a JMS transaction and read a message from a queue, then re-use the transaction for data access through Hibernate. If anything goes wrong, the JMS and database transaction would both be rolled back, without using 2-phase commit (2PC).
I'm not much of a transaction guru, so before I start digging deeper, can anyone confirm that this is possible and makes sense as well?
Update:
What I want is an implementation of the Shared Transaction Resource pattern. The sample code demonstrates it for ActiveMQ and JDBC, but I need to use Oracle Streams AQ and Hibernate.
Update2:
The SpringSource Advanced Pack for Oracle has been open sourced as part of Spring Data JDBC and it "provides the option of using a single local transaction manager for both
database and message access without resorting to expensive distributed 2-phase commit
transaction management".
2PC shouldn't be necessary, as you say, since the appserver should take care of it. However, you'll pretty much have to use JTA (i.e. JavaEE container) transactions, rather than vanilla DataSource transactions, since JMS only works with JTA.
This isn't a big deal, it's just a bit more fiddly:
Your Spring config should use
<jee:jndi-lookup/> to get a
reference to your container's
DataSource, and you inject that
data source into your spring-managed
hibernate SessionFactory.
You then need to introduce a transaction manager into the context (<tx:jta-transaction-manager/> should work in most app-servers).
In your Spring JMS MessageListenerContainer, plug the above transaction manager reference into it.
Does that all make sense, or should I elaborate? This setup should ensure that the container-managed transactions are held across JMS and Hibernate interactions.