On 08/01/2013 10:41 AM, Scott Marlow wrote:
>> - The shared non-thread-safe content finding looks like it
>> symptom of a real bug: in the method 'getNamedEntityManagerFactory',
>> 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
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
is reading an unprotected Set that could be updated concurrently from a
Any other feedback about this thread safety bug before I create a HHH jira?
HHH-8406 is for fixing the thread safety issue.
hibernate-dev mailing list