Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TransactionAwareDataSourceProxy should mask out calls to setAutoCommit() [SPR-6441] #11107

Closed
spring-issuemaster opened this issue Nov 24, 2009 · 5 comments

Comments

@spring-issuemaster
Copy link
Collaborator

@spring-issuemaster spring-issuemaster commented Nov 24, 2009

Dave Syer opened SPR-6441 and commented

TransactionAwareDataSourceProxy should mask out calls to setAutoCommit(). It masks commit and rollback already, but legacy code can still manipulate other settings that we want Spring the transaction manager to handle.


2 votes, 4 watchers

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Jun 13, 2010

Wouter Coekaerts commented

It masks commit and rollback already
Where does it do that? I don't see that mentioned anywhere. Not in the documentation, and not when reading the code.
In TransactionAwareDataSourceProxy.TransactionAwareInvocationHandler, close() is handled specifically, but commit() and rollback() are just passed to the target Connection.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Jun 13, 2010

Dave Syer commented

Hmm, I think you might be right there. I guess I only worked with use cases where autoCommit is the true (so no-one calls commit or rollback explicitly). Those calls should be masked as well, it seems.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Jun 18, 2012

Rossen Stoyanchev commented

This issue has been resolved through a selective bulk update, as part of a larger effort to better manage unresolved issues. To qualify for the update, the issue was either created before Spring 3.0 or affects a version older than Spring 3.0 and is not a bug.

There is a good chance the request was made obsolete, or at least partly outdated, by changes in later versions of Spring including deprecations. It is also possible it didn't get enough traction or we didn't have enough time to address it. One way or another, we didn't get to it.

If you believe the issue, or some aspects of it, are still relevant and worth pursuing at present you may re-open this issue or create a new one with a more up-to-date description.

We thank you for your contributions and encourage you to become familiar with the current process of managing Spring Framework JIRA issues that has been in use for over a year.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Sep 2, 2013

Elryk commented

To mask the commit and the rollback methods, we could add a PlatformTransactionManager to the TransactionAwareDataSourceProx's constructor and add the following code into the TransactionAwareDataSourceProxy inner class:

if (method.getName().equals("commit")) {
   TransactionStatus status = transactionManager.getTransaction(this);
   transactionManager.commit(status);
   return null;
} else if (method.getName().equals("rollback")) {
   TransactionStatus status = transactionManager.getTransaction(this);
   transactionManager.rollback(status);
   return null;
} 
@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Sep 25, 2015

Juergen Hoeller commented

TransactionAwareDataSourceProxy and co weren't really meant to deal with legacy code but rather just with pure data access operations that happen to fetch a JDBC Connection from a DataSource and call close() on it eventually. Any other interactions are not desirable but not really meant to be suppressed either. So if there's no real pain, I'd rather leave this as-is.

Juergen

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.