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 aDataSource
as well? And wouldn't this be a slippery slope? Shouldn't theDataSource
, when used with multi tenancy, be a proxy/delegate that eventually operates on the actual instance (like theAbstractRoutingDatasource
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.