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

Background initialization for Hibernate SessionFactory breaks transaction management [SPR-14379] #18952

Closed
spring-projects-issues opened this issue Jun 17, 2016 · 2 comments
Assignees
Labels
in: data Issues in data modules (jdbc, orm, oxm, tx) type: bug A general bug
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Jun 17, 2016

Manuel Dominguez Sarmiento opened SPR-14379 and commented

SpringSessionContext.currentSession() invokes TransactionSynchronizationManager.getResource(this.sessionFactory) and TransactionSynchronizationManager maintains a Map of resource references keyed by object references. Ordinarily this is not a problem when invoking TransactionSynchronizationManager.getResource(this.sessionFactory) since the SessionFactory reference is always the same.

However, when background initialization of the SessionFactory is enabled (new feature in 4.3 GA as per #18305) then the SessionFactory can turn out to be a proxy created using a LocalSessionFactoryBuilder$BootstrapSessionFactoryInvocationHandler depending on how the SessionFactory reference was obtained. Thus the map key for TransactionSynchronizationManager will be different. So effectively this will cause SpringSessionContext.currentSession() to return different Hibernate SessionImpl instances within the same thread and transaction context. Meaning all hell breaks loose when this happens.

TransactionSynchronizationManager.getResource() invokes TransactionSynchronizationUtils.unwrapResourceIfNecessary(key) before attempting to use the key as provided. This method's name seems to imply that it would solve the proxy wrapping issue described above, however it does not. It only checks for InfrastructureProxy and ScopedProxyUnwrapper, but neither resolves the issue described here.

The workaround is not to use background initilization as per #18305 (i.e. avoiding configuration of a bootstrapExecutor for LocalSessionFactoryBean). The solution would probably involve either fixing TransactionSynchronizationUtils.unwrapResourceIfNecessary() or having the LocalSessionFactoryBuilder$BootstrapSessionFactoryInvocationHandler proxy implement InfrastructureProxy so that the correct SessionFactory reference could be unwrapped.


Affects: 4.3 GA

Issue Links:

Referenced from: commits 01f1158

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

The exposed bootstrap proxy implements the InfrastructureProxy interface now, unwrapping the underlying SessionFactory. This should address the problem that you've outlined for scenarios where the native SessionFactory is being accessed directly in some places.

@spring-projects-issues
Copy link
Collaborator Author

Manuel Dominguez Sarmiento commented

Thanks Juergen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: data Issues in data modules (jdbc, orm, oxm, tx) type: bug A general bug
Projects
None yet
Development

No branches or pull requests

2 participants