>> - The shared non-thread-safe content finding looks like it spots a >> symptom of a real bug: in the method 'getNamedEntityManagerFactory', a >> hashmap is extracted from a concurrent hash map and read from. >> Concurrently, there is the possibility that items are removed from the >> hash maps. There is no common lock guarding these accesses. This may >> cause, at worst, infinite loops, if the hashmap is accessed in an >> inconsistent state. > I actually have no idea why it keeps a Set for each name. Seems to me > the code ultimately throws an exception anyway if more than one was > registered under that name, so why not just store > name->EntityManagerFactory? Scott?
We could of thrown an exception if more than one was registered under that name but Emmanuel had a good concern about how that would break Hibernate applications that are clustered in some platforms (as well as applications that serialize/deserialize the EntityManagerFactory). Instead of throwing an exception when multiple EMFs are added under the same name, we log a warning and track the multiple EMFs registered under a particular name. However, we do throw an exception only when the attempt to deserialize the EMF by name but there are more than one EMFs registered (see EntityManagerFactoryRegistry.getNamedEntityManagerFactory(String name)). The distinction is that applications might create multiple EMFs with the same name and we allow that but will throw an error, for the smaller set of apps that actually try to deserialize the EMF by name. It does look like EntityManagerFactoryRegistry.getNamedEntityManagerFactory(String name), is reading an unprotected Set that could be updated concurrently from a different thread. Any other feedback about this thread safety bug before I create a HHH jira? Scott _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
