Community
Participate
Working Groups
The public static variables EntityManagerFactoryProvider.initialEmSetupImpls and EntityManagerFactoryProvider.initialPuInfos are both implemented as non-thread safe HashMap but the potential exists for concurrent modification. These collections are created and assigned in JavaSECMPInitializer.initialize and remove() is called on initialEmSetupImpls in PersistenceProvider.createEntityManagerFactory. In the Java SE and EE environments concurrency is not an issue. However in OSGi concurrency is possible and rather than hope concurrency doesn't corrupt these lists code should be put in place to ensure they are not corrupted. Ongoing work and learnings in Gemini may require this bug be "escalated".
Setting target and priority. See the following page for details of the meanings of these fields: http://wiki.eclipse.org/EclipseLink/Development/Bugs/Guidelines
Created attachment 184183 [details] Patch Resolves bug by initializing public maps statically to Hashtables. Patch also removes conditional code with null checks since the maps are not never null.
>Shaun, patch looks good I assume that Hashtable is being used instead of ConcurrentHashMap so that the read locking behavior of Hashtable assures us of synchronization - at the expense of a slight performance penalty. I expect that the configurable concurrencyLevel of ConcurrentHashMap would not gaurantee contention since the number of users is unknown. - the removed NPE checks are ok - we just need to test running an SE persistence unit in an EE container - see initialize()
Patch applied in SVN tx 8605.
Reopening to address concerns raised by Andrei. Revised fix in progress.
Created attachment 184907 [details] Suggested patch The patch associates JPAInitializers with their initializationClassloader. Initializer now can hold initialPuInfos and initialEmSetupImpls (those used to be statics). Also initializer keeps a list of emSetupImpls that has at least one factory associated with them. The main scenarious are: SE with agent (no redeployment is possible). Only one initializer (corresponding to the system classloader) is created. No changes in functionality. SE without agent. Redeployment is possible AND Eclipselink is not notified on undeployment. Therefore initialPuInfos and initialEmSetupImpls are not created (otherwise if no factory was ever created the may linger after redeployment forever). No changes in functionality - possible multiple initializers - one per class loader. As before the change the xml archive is read each time a new pu is created. Initializer is removed when no factories left. OSGi. Redeployment is possible and controled. On undeploy loop through all emSetupImpls cached on the initializer corresponding to the classloader being undeployed and undeploy them all.
Created attachment 184991 [details] patch - take 2 Assorted fixes for concurrency and some exceptions handling.
Resolved by Bug 332743.
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
