If JpaTransactionManager is used in a multitenant setup then the dataSource is not thread safe. This is in contrast to the TransactionSynchronizationMangager which uses ThreadLocals to manage its fields.

Comment From: pivotal-cla

@bwilsonPaychex Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

Comment From: pivotal-cla

@bwilsonPaychex Thank you for signing the Contributor License Agreement!

Comment From: mdeinum

Wouldn't this apply to the other PlatformTransactionManager that operate on a DataSource as well? And wouldn't this be a slippery slope? Shouldn't the DataSource, when used with multi tenancy, be a proxy/delegate that eventually operates on the actual instance (like the AbstractRoutingDatasource for instance).

Comment From: bwilsonPaychex

Wouldn't this apply to the other PlatformTransactionManager that operate on a DataSource as well? And wouldn't this be a slippery slope? Shouldn't the DataSource, when used with multi tenancy, be a proxy/delegate that eventually operates on the actual instance (like the AbstractRoutingDatasource for instance).

Are you referring the HibernateTransactionManager? If so, then yes I can make the change there as well. We do not use that one but it would have the same issue.

As per slippery slope, I can tell you much of the code in JpaTransactionManager is assuming the dataSource isn't switched during processing hence why the ThreadLocal was needed. Using the ThreadLocal did completely solve the issue we had

Comment From: snicoll

Thanks for the PR @bwilsonPaychex but we can't really consider it without some tests that exercise (and fix) the behavior you've described. Can you please add some?

Comment From: snicoll

I am going to close this now, as the lack of tests is troubling and I agree that it would be a slippery slope. If the tests are provided we can reopen and continue the review.