[
https://issues.jboss.org/browse/HIBERNATE-152?page=com.atlassian.jira.plu...
]
Karl von Randow commented on HIBERNATE-152:
-------------------------------------------
I believe I have just encountered this issue, but with DatasourceConnectionProviderImpl
and specifically a race to complete {{configure(Map)}} and calling {{getConnection()}}.
I have two threads that both start at the same time, immediately after the
{{SessionFactory}} has been created. It appears that the first thread creates the
{{ConnectionProvider}} service and then configures it, while the second thread gets the
unconfigured {{ConnectionProvider}} service instance and tries to use it, calling
{{getConnection}} and failing because it is not configured.
I can reproduce this quite reliably (although not every time, by nature of the race
condition) in my development environment. I am happy to test a solution.
ServiceRegistry race condition
------------------------------
Key: HIBERNATE-152
URL:
https://issues.jboss.org/browse/HIBERNATE-152
Project: Hibernate Integration
Issue Type: Bug
Reporter: rob moffat
Assignee: Steve Ebersole
Priority: Minor
If I have multiple threads, all trying to use StatementPreparer, then what happens is
that they all get a RefCursorSupport from the service registry, and start using it.
The problem is, the initialisation process is: 1) create the instance of
RefCursorSupport, 2) add it to the service registry, 3) then initialise the fields on it
(specifically, jdbcServices).
However, because the object is available from the service registry after creation, but
before initialisation, the other threads can pull this back and start using it without
jdbcServices initialised.
This is a pervasive problem for all the objects in the service registry which have
injected services that they depend on, I would think. I'm very surprised this
hasn't been spotted sooner and fixed.
cheers,
Rob
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)