[jboss-jira] [JBoss JIRA] (HIBERNATE-152) ServiceRegistry race condition

[Karl von Randow (JIRA)]

    [ https://issues.jboss.org/browse/HIBERNATE-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13129496#comment-13129496 ] 

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)