aspose file tools*
The moose likes Spring and the fly likes Spring @Transaction Rollback problem Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Frameworks » Spring
Bookmark "Spring @Transaction Rollback problem " Watch "Spring @Transaction Rollback problem " New topic
Author

Spring @Transaction Rollback problem

anakin volpy
Greenhorn

Joined: Jul 26, 2010
Posts: 18
Hey Guys,
I'm having some trouble rolling back a spring transaction once deployed to weblogic 10.3 using a datasource connection pool. My JUnit test rolls back fine but once deployed it seems like the JDBC connection is being returned to the datasource before the roll back.

Here is the log info comparisons.

JUnit Log
2012-08-23 15:26:01,071 DEBUG [main] (DataSourceTransactionManager) - Creating new transaction with name [com.yes.delegate.ITxService.handleAcdnt]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT
2012-08-23 15:26:01,071 DEBUG [main] (DataSourceTransactionManager) - Acquired Connection [jdbcracle:thin:@ldap://prod.yes.yes.com:389/TESTDB,cn=OracleContext,dc=yes,dc=yes,dc=com, UserName=USRNM, Oracle JDBC driver] for JDBC transaction
2012-08-23 15:26:01,071 DEBUG [main] (DataSourceTransactionManager) - Switching JDBC Connection [jdbcracle:thin:@ldap://prod.yes.yes.com:389/TESTDB,cn=OracleContext,dc=yes,dc=yes,dc=com, UserName=USRNM, Oracle JDBC driver] to manual commit
2012-08-23 15:26:01,071 INFO [main] (TxService) - txHandleAccident
2012-08-23 15:26:01,071 DEBUG [main] (JdbcTemplate) - Executing prepared SQL query
2012-08-23 15:26:01,071 DEBUG [main] (JdbcTemplate) - Executing prepared SQL statement [SELECT tcsg.nextval FROM dual]
2012-08-23 15:26:01,087 DEBUG [main] (JdbcTemplate) - Executing prepared SQL update
2012-08-23 15:26:01,087 DEBUG [main] (JdbcTemplate) - Executing prepared SQL statement [INSERT INTO tc() VALUES()]
2012-08-23 15:26:01,087 DEBUG [main] (StatementCreatorUtils) - Setting SQL statement parameter value: column index 1, parameter value [1234], value class [java.lang.String], SQL type 12
2012-08-23 15:26:01,087 DEBUG [main] (StatementCreatorUtils) - Setting SQL statement parameter value: column index 2, parameter value [1234], value class [java.lang.String], SQL type 12
2012-08-23 15:26:01,087 DEBUG [main] (StatementCreatorUtils) - Setting SQL statement parameter value: column index 3, parameter value [1234.0], value class [java.lang.Double], SQL type 8
2012-08-23 15:26:01,087 DEBUG [main] (StatementCreatorUtils) - Setting SQL statement parameter value: column index 4, parameter value [1234.0], value class [java.lang.Double], SQL type 8
2012-08-23 15:26:01,087 DEBUG [main] (StatementCreatorUtils) - Setting SQL statement parameter value: column index 5, parameter value [rollback test], value class [java.lang.String], SQL type 12
2012-08-23 15:26:01,087 DEBUG [main] (JdbcTemplate) - SQL update affected 1 rows
2012-08-23 15:26:01,087 INFO [main] (TxService) - SUCCESSFULLY INSERT INTO TC
2012-08-23 15:26:01,087 DEBUG [main] (JdbcTemplate) - Executing prepared SQL update
2012-08-23 15:26:01,087 DEBUG [main] (JdbcTemplate) - Executing prepared SQL statement [This statement fails. want to roll back previous insert]
2012-08-23 15:26:01,087 DEBUG [main] (StatementCreatorUtils) - Setting SQL statement parameter value: column index 1, parameter value [1234], value class [java.lang.String], SQL type 12
2012-08-23 15:26:01,087 DEBUG [main] (StatementCreatorUtils) - Setting SQL statement parameter value: column index 2, parameter value [1234.0], value class [java.lang.Double], SQL type 8
2012-08-23 15:26:01,087 DEBUG [main] (StatementCreatorUtils) - Setting SQL statement parameter value: column index 3, parameter value [2012-08-23T15:26:01.024-04:00], value class [org.apache.xmlbeans.XmlCalendar], SQL type 93
2012-08-23 15:26:01,087 DEBUG [main] (JdbcTemplate) - SQL update affected 0 rows
2012-08-23 15:26:01,087 INFO [main] (EIDao) - Error Updating eq. Returned 0 Rows Updated.
2012-08-23 15:26:01,087 ERROR [main] (TxService) - ERROR: Error updating eq
2012-08-23 15:26:01,087 INFO [main] (TxException) - Handling Tx Exception
2012-08-23 15:26:01,087 DEBUG [main] (DataSourceTransactionManager) - Triggering beforeCompletion synchronization
2012-08-23 15:26:01,087 DEBUG [main] (DataSourceTransactionManager) - Initiating transaction rollback
2012-08-23 15:26:01,087 DEBUG [main] (DataSourceTransactionManager) - Rolling back JDBC transaction on Connection [jdbcracle:thin:@ldap://prod.yes.yes.com:389/TESTDB,cn=OracleContext,dc=yes,dc=yes,dc=com, UserName=USRNM, Oracle JDBC driver]
2012-08-23 15:26:01,087 DEBUG [main] (DataSourceTransactionManager) - Triggering afterCompletion synchronization
2012-08-23 15:26:01,087 DEBUG [main] (DataSourceTransactionManager) - Releasing JDBC Connection [jdbcracle:thin:@ldap://prod.yes.yes.com:389/TESTDB,cn=OracleContext,dc=yes,dc=yes,dc=com, UserName=USRNM, Oracle JDBC driver] after transaction
2012-08-23 15:26:01,087 DEBUG [main] (DataSourceUtils) - Returning JDBC Connection to DataSource




Server Log
2012-08-24 09:27:36,967 DEBUG [5] (DataSourceTransactionManager) - Creating new transaction with name [com.yes.delegate.ITxService.handleAcdnt]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT
2012-08-24 09:27:36,968 DEBUG [5] (DataSourceTransactionManager) - Acquired Connection [weblogic.jdbc.wrapper.PoolConnection_oracle_jdbc_driver_T4CConnection@a085] for JDBC transaction
2012-08-24 09:27:36,971 DEBUG [5] (DataSourceTransactionManager) - Switching JDBC Connection [weblogic.jdbc.wrapper.PoolConnection_oracle_jdbc_driver_T4CConnection@a085] to manual commit
2012-08-24 09:27:36,976 INFO [5] (TxService) - txHandleAccident
2012-08-24 09:27:36,977 DEBUG [5] (JdbcTemplate) - Executing prepared SQL query
2012-08-24 09:27:36,977 DEBUG [5] (JdbcTemplate) - Executing prepared SQL statement [SELECT tcsg.nextval FROM dual]
2012-08-24 09:27:36,977 DEBUG [5] (DataSourceUtils) - Fetching JDBC Connection from DataSource
2012-08-24 09:27:36,977 DEBUG [5] (DataSourceUtils) - Registering transaction synchronization for JDBC Connection
2012-08-24 09:27:36,979 DEBUG [5] (JdbcTemplate) - Executing prepared SQL update
2012-08-24 09:27:36,979 DEBUG [5] (JdbcTemplate) - Executing prepared SQL statement [INSERT INTO tc(qry)]
2012-08-24 09:27:36,980 DEBUG [5] (StatementCreatorUtils) - Setting SQL statement parameter value: column index 1, parameter value [1234], value class [java.lang.String], SQL type 12
2012-08-24 09:27:36,980 DEBUG [5] (StatementCreatorUtils) - Setting SQL statement parameter value: column index 2, parameter value [1234], value class [java.lang.String], SQL type 12
2012-08-24 09:27:36,980 DEBUG [5] (StatementCreatorUtils) - Setting SQL statement parameter value: column index 3, parameter value [1234.0], value class [java.lang.Double], SQL type 8
2012-08-24 09:27:36,980 DEBUG [5] (StatementCreatorUtils) - Setting SQL statement parameter value: column index 4, parameter value [1234.0], value class [java.lang.Double], SQL type 8
2012-08-24 09:27:36,980 DEBUG [5] (StatementCreatorUtils) - Setting SQL statement parameter value: column index 5, parameter value [Test String Rollback], value class [java.lang.String], SQL type 12
2012-08-24 09:27:36,981 DEBUG [5] (JdbcTemplate) - SQL update affected 1 rows
2012-08-24 09:27:36,981 INFO [5] (TxService) - SUCCESSFULLY INSERT INTO TC
2012-08-24 09:27:36,982 DEBUG [5] (JdbcTemplate) - Executing prepared SQL update
2012-08-24 09:27:36,982 DEBUG [5] (JdbcTemplate) - Executing prepared SQL statement [This statement fails. want to roll back previous insert]
2012-08-24 09:27:36,982 DEBUG [5] (StatementCreatorUtils) - Setting SQL statement parameter value: column index 1, parameter value [1234], value class [java.lang.String], SQL type 12
2012-08-24 09:27:36,982 DEBUG [5] (StatementCreatorUtils) - Setting SQL statement parameter value: column index 2, parameter value [1234.0], value class [java.lang.Double], SQL type 8
2012-08-24 09:27:36,983 DEBUG [5] (StatementCreatorUtils) - Setting SQL statement parameter value: column index 3, parameter value [2012-08-24T09:05:41.000-04:00], value class [org.apache.xmlbeans.XmlCalendar], SQL type 93
2012-08-24 09:27:36,986 DEBUG [5] (JdbcTemplate) - SQL update affected 0 rows
2012-08-24 09:27:36,986 INFO [5] (EIDao) - Error Updating eq. Returned 0 Rows Updated.
2012-08-24 09:27:36,987 ERROR [5] (TxService) - ERROR: Error updating eq
2012-08-24 09:27:36,988 INFO [5] (TxException) - Handling Tx Exception
2012-08-24 09:27:36,991 DEBUG [5] (DataSourceTransactionManager) - Triggering beforeCompletion synchronization
2012-08-24 09:27:36,993 DEBUG [5] (DataSourceUtils) - Returning JDBC Connection to DataSource
2012-08-24 09:27:36,993 DEBUG [5] (DataSourceTransactionManager) - Initiating transaction rollback
2012-08-24 09:27:36,993 DEBUG [5] (DataSourceTransactionManager) - Rolling back JDBC transaction on Connection [weblogic.jdbc.wrapper.PoolConnection_oracle_jdbc_driver_T4CConnection@a085]
2012-08-24 09:27:36,994 DEBUG [5] (DataSourceTransactionManager) - Triggering afterCompletion synchronization
2012-08-24 09:27:36,996 DEBUG [5] (DataSourceTransactionManager) - Releasing JDBC Connection [weblogic.jdbc.wrapper.PoolConnection_oracle_jdbc_driver_T4CConnection@a085] after transaction
2012-08-24 09:27:36,996 DEBUG [5] (DataSourceUtils) - Returning JDBC Connection to DataSource




My JUnit test does not call directly into the TX Service I call a standard Service Layer that calls the TX Service. The weblogic deployed layer is a standard Spring web service follows the flow endpoint --> service layer --> Tx Service.

Here is my @Transaction annotated method


Here is my configuration



Let me know if more info is needed. Thanks
anakin volpy
Greenhorn

Joined: Jul 26, 2010
Posts: 18
Hmmm maybe this is useful as well. dataSource's I'm using in the service deployment and my jUnit are different.

My service deployment is using.



jUnit is using


Could this possibly be causing the prob?
Bill Gorder
Bartender

Joined: Mar 07, 2010
Posts: 1680
    
    7

I don't know what your Junit looks like but lets assume your are using interface based proxies and your @Transactional is in a Spring bean and you are accessing that method through an interface. I will make these assumptions since you say you have it working in your 'Junit' . Why you are using an Oracle database for unit testing is a bit confusing to me. Do you have the default auto commit property set to false?


[How To Ask Questions][Read before you PM me]
anakin volpy
Greenhorn

Joined: Jul 26, 2010
Posts: 18
Sorry, junit test is not the correct term here. I guess its more of an integration test I came up with because I was new to spring transactions. I wanted to make sure i could configure them and get them to work locally before throwing it into a deployed web app. Im actually not sure what my auto-comit is set to. Is this a data source property? I currently dont have all the information in front of me right now.

But my txDelegate is called from an interface and i currently do not have an interface defined for my txDelegate.
Bill Gorder
Bartender

Joined: Mar 07, 2010
Posts: 1680
    
    7

For the basicDataSource just set the property




For the other case where you are looking up your datasource via JNDI I would typically use the JtaTransactionManager not the DataSourceTransactionManager but in your case since you are running on Weblogic you should probably be using the WebLogicJtaTransactionManager
anakin volpy
Greenhorn

Joined: Jul 26, 2010
Posts: 18


Hmmm. There isn't an auto-commit for this factory. Also with the WebLogicJtaTransactionalManager, you arn't setting a dataSource like like you do with the DataSourceTransactionManager




If I choose thet WebLogicJtaTransactionalManager route, do I have to do AOP at this point.

Bill Gorder
Bartender

Joined: Mar 07, 2010
Posts: 1680
    
    7

I think you can add



and it will correctly detect and use the correct one (in your case weblogic)
anakin volpy
Greenhorn

Joined: Jul 26, 2010
Posts: 18
Yea this basically does the same thing as setting the WebLogicJtTransactionManager bean, but still doesn't solve any problems. When I do this, I don't even get an attempted rollback like I do when simply using the DataSourceTransactionManager. I'm guessing I somehow need to pass my datasource



Into my transactionManager, but I seem to be lost on the configuration.
Bill Gorder
Bartender

Joined: Mar 07, 2010
Posts: 1680
    
    7

You don't associate datasources with the transactionmanager or the other way round when using JTA.

You may not have it configured, I don't know much about WebLogic.

So you have the datasource set up in Weblogic and you are using JdbcTemplate? Or are you using Hibernate or JPA?

It seems to me what you had here should work. It wont be using JTA or CMT but it should work.





I guess you could try using






Bill Gorder
Bartender

Joined: Mar 07, 2010
Posts: 1680
    
    7

Make sure your deployment descriptors are all present and configured correctly too. (web.xml and weblogic.xml)
)
http://cognitivecache.blogspot.com/2009/01/configuring-jdbc-datasource-in-weblogic.html
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17259
    
    6

OK "Anakin"

What Bill is saying is correct. When you do a JNDI lookup, you are only looking up the DataSource, but nothing about setting up Transaction management in Spring to use Weblogic's JTA Transaction Manager.
You do not need to set an auto-commit property.

To set up the transaction manager just use

<tx:jta-transaction-manager/> It will automatically see that you are in Weblogic and use the correct class.

Also for <tx:annotation-driven/> That is all you need. The transaction manager property is defaulted to "transactionManager"

Also, for your jndi lookup, use the jee:jndi-lookup tag instead, it is cleaner, less typing.

And I said all of this in the class too. ;)

Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Bill Gorder
Bartender

Joined: Mar 07, 2010
Posts: 1680
    
    7

Mark Spritzler wrote:
And I said all of this in the class too. ;)
Mark


I wasn't invited
anakin volpy
Greenhorn

Joined: Jul 26, 2010
Posts: 18
hmmm. I feel I have everything configured correctly.

Heres what I setup. But still doesn't seem to work.


Maybe my problem is rooted deeper. Possibly my versioning or the way my contexts are configured. I'm writing a Spring Web Service using the DispatcherServlet. I'm guessing the DispatcherServlet is the child context while I have my business beans defined in the root context. Is there anyway that requests go through the DispatcherSerlvet and somehow bypass the transactioning that is defined. I could be way off base here. Here is what I have in my descriptor. Anything look fishy here? And no Mark, I my actual beans are not defined a,b,c,d,e,f,g etc.... heheh. The below values are just fillers.




Thanks for all the help thus far.
anakin volpy
Greenhorn

Joined: Jul 26, 2010
Posts: 18
Still kinda stuck here. I've tried many different configurations but when I send a request into the service there's never any indication that there any beans being configured/proxied and no work being done by the transaction manager which leads me to think I'm messing up some high level configuration.


In my integration test when I was using the DataSourceTransactionManager I could atleast see some info regarding acquired connections etc.. But I'm not seeing anything like such with any other configuration.
Bill Gorder
Bartender

Joined: Mar 07, 2010
Posts: 1680
    
    7

You have an a-service-servlet.xml config file to then. What is in that?

Also I don't see any resource-ref did you read that link I posted?
anakin volpy
Greenhorn

Joined: Jul 26, 2010
Posts: 18
the a-service-servlet has most of the spring web-service setup adapters and mapping handlers. (I'll post it below, nothing fancy in there) I do know that the DispatcherServlet automatically creates a servlet file based on the servlet-name defined in name.

So

Automatically creates an a-service-servlet.xml which becomes a child of my root context. Though it seems I am also defining the a-service-servlet in the contextConfig.




I did look over the link you posted. For all of our data access clases we extend JdbcDaoSupport. I don't feel comfortable having to do a context lookup and grabbing connections in my dao code. Thanks for the info though. I may mess around with that anyway to see exactly how it behaves.


Any other ideas. Is there anyway the requests come into a context where transactions are not enabled. I think I even tried doing a declarative aop approach instead of using annotations and but still no cigar.
Bill Gorder
Bartender

Joined: Mar 07, 2010
Posts: 1680
    
    7

Though it seems I am also defining the a-service-servlet in the contextConfig.


Thats what I was wondering but it was hard to tell with a,b,c

You do not want to do that. You are initializing that twice, this can cause issues with the same beans being defined in both contexts. You need to either remove it from the root context or remove it from the servlet context (thereby scoping everything to the root context) you can do this by providing an empty param tag for the dispatcher servlet (see below). Also if you have component scans in the a-service-servlet.xml (and you have not chosen to define everything in the root context) you can run into the same problem. You did not post the contents of this file so you will have to look for yourself.



You should not have to extend JdbcDaoSupport or have the need to mess with the connection at all. Also this has absolutely nothing to do with the link I posted regardless of whether you choose to extend JdbcDaoSupport or not.

You need the part about your web.xml and I am not familiar with Weblogic but you probably need the part about weblogic.xml. You obviously can ignore the jndi look up stuff at the bottom that is covered by your jee:jndi-lookup tag .
anakin volpy
Greenhorn

Joined: Jul 26, 2010
Posts: 18
Hey Bill, Thanks for the info. I modified the post above to include the generic "a" names to stay consistent with other posts.

I took your advice and basically just scoped everything as root context to see what would happen. I also tried the original way I had it and just removed the a-service-servlet from the contextConfigLocation parameter so duplicate beans were not being defined in 2 contexts.

Regarding the link. I don't have a problem grabbing connections from the connection pool. The link is just an alternative to the way I have it configured. I bring up the JdbcDaoSupport class because the way I have it configured w/ spring.

eiDao extends JdbcDaoSupport


So its kinda all doing the same thing.

Still no solution to the original problem though after trying whats mentioned above.

Bill Gorder
Bartender

Joined: Mar 07, 2010
Posts: 1680
    
    7

I would just scope everything to the root context for now. It is safer at least until you can figure out what the issue is. Since it works with a local datasource and it does not work with a jndi lookup from Weblogic my guess is that that is where your problem is.

Are you defining connection pools in your application? If you are do not do this if you are using a container.

See here for some more info on stuff that is related

http://docs.oracle.com/cd/E15051_01/wls/docs103/webapp/configureresources.html
http://stackoverflow.com/questions/47676/tomcat-vs-weblogic-jndi-lookup
http://stackoverflow.com/questions/2887967/what-is-resource-ref-in-web-xml-used-for

I know when using Websphere for example failure to define that in the web.xml will prevent you from even exposing that datasource to the application properly when you are installing it. I am not familiar once again with weblogic but I think you are missing something.


You need to do all the necessary configuration both in your application and on Weblogic to insure that the datasource is being properly configured and managed by the container.
Bill Gorder
Bartender

Joined: Mar 07, 2010
Posts: 1680
    
    7

When you are using the jndi lookup you are commenting out all the code related to your basic datasource and its transaction management right? I just want to make sure we only have one transaction manager and one jee-jndi lookup for the datasource and that is all.

Also a good test to see if you have a transaction is do something like this and step through with a debugger, and just see what is going on.




Alternatively if you are not running a Weblogic locally for debugging then try to leave the jndi stuff but deploy it to Tomcat instead. Does it work then? If it does you know its some sort of Weblogic configuration issue.
anakin volpy
Greenhorn

Joined: Jul 26, 2010
Posts: 18
Ok, here's a solution I'm going to go with. Not sure if this is the "right" way, but this seems to work. I basically went back to my originally defined DataSourceTransactionManager



And noticed that there seemed to 2 JDBC connections returned to the DataSource
2012-08-24 09:27:36,988 INFO [5] (TxException) - Handling Tx Exception
2012-08-24 09:27:36,991 DEBUG [5] (DataSourceTransactionManager) - Triggering beforeCompletion synchronization
2012-08-24 09:27:36,993 DEBUG [5] (DataSourceUtils) - Returning JDBC Connection to DataSource
2012-08-24 09:27:36,993 DEBUG [5] (DataSourceTransactionManager) - Initiating transaction rollback
2012-08-24 09:27:36,993 DEBUG [5] (DataSourceTransactionManager) - Rolling back JDBC transaction on Connection [weblogic.jdbc.wrapper.PoolConnection_oracle_jdbc_driver_T4CConnection@a085]
2012-08-24 09:27:36,994 DEBUG [5] (DataSourceTransactionManager) - Triggering afterCompletion synchronization
2012-08-24 09:27:36,996 DEBUG [5] (DataSourceTransactionManager) - Releasing JDBC Connection [weblogic.jdbc.wrapper.PoolConnection_oracle_jdbc_driver_T4CConnection@a085] after transaction
2012-08-24 09:27:36,996 DEBUG [5] (DataSourceUtils) - Returning JDBC Connection to DataSource


Combined with the fact Bill brought of me initilizing a-servlet.xml twice because of the following web.xml setup. (a-servlet.xml is configured by both the dispatcherServlet by default, and in my contextconfigLocation)



So I basically just scoped everything as root, as you mentioned, and went back to the DataSourceTrasaction manager and it works. I'm honestly not sure why the weblogicjtatransaction manager wouldn't configure correctly, but since this works, i'm going to run with it and move forward.


Do you guys see a possible issue with going with this configuration? If not, thanks for all the help. I learned a lot with the info you provided.
Bill Gorder
Bartender

Joined: Mar 07, 2010
Posts: 1680
    
    7

Do you guys see a possible issue with going with this configuration? If not, thanks for all the help. I learned a lot with the info you provided.


You lose any of the advantages gained by JTA. Is that an issue? Maybe, maybe not. Nobody on this forum is going to be able to answer that as none of us know enough about your project or environment. I would definitely bring it up to your tech lead/architect. I am sure they can tell you if it is acceptable or not. You are of course welcome and good luck!
Bill Gorder
Bartender

Joined: Mar 07, 2010
Posts: 1680
    
    7

Still no solution to the original problem though after trying whats mentioned above


If you find out you do need to get it working with Weblogic do not forget that you did not try adding the following to your web.xml



and adding a weblogic.xml in your WEB-INF directory

name space depends on version of Weblogic but see their documentation for an example.



The documentation makes it sound like its required, but for whatever reason you were unwilling to try it. I am not convinced that adding these and reinstalling your app on weblogic would not have solved the problem. Or at least produced some sort of meaningful exception. This assumes you are using the below in your config.



In any event I thought I would put this in here for future readers to try if they are having a similar problem

Good luck.

viren patil
Greenhorn

Joined: Sep 11, 2012
Posts: 1
you would like to set each service method to @Transactional with proper propogation or read only then only the proxy determine properly to maintain the commit operation.
 
Don't get me started about those stupid light bulbs.
 
subject: Spring @Transaction Rollback problem