[hibernate-dev] Static analysis report on thread safety of Hibernate

[Scott Marlow]

>> - 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