Hi Andrei,
Unfortunately you haven't seen the Gemini JPA code that relies
on these EclipseLink changes because Mike Keith is waiting for these
changes to show up in EclipseLink before we apply the Gemini
updates.
On 12/7/2010 4:15 PM, Andrei Ilitchev wrote:
JPAInitializer: why to add an extra parameter to
registerTransformer
(Map properties)? The only use of the existing parameter puInfo is
to
print out puName - for FINER logging.
In Gemini OSGi JPA I need to pass properties down to the
transformer, specifically the Bundle name and version.
EntityManagerFactoryProvider: both initialEmSetupImpls and
initialPuInfos are used only in JavaSE case (not OSGi) - why both
their
class and initial values are changed? They should not be.
They are referenced in PersistenceProvider which is not just SE.
The Gemini code path will hit them.
HashMap is used so that get doesn't lock the map - Hashtable's
locking
get method would cause performance deterioration.
So we use a highly concurrent map, but truth be told this code is
not highly contended.
There is no concurrency concerns for initialPuInfos - it's used
(if
used at all) only once during initialization;
Again, referenced in PersistenceProvider and in Gemini
initialization happens as bundles come and go.
Possible concurrency issues for initialEmSetupImpls resolved by
synchronized (EntityManagerFactoryProvider.emSetupImpls) statement
in
PersistenceProvider (one for put, another for remove).
I think ConcurrentHashMap is a more concurrent solution.
Initial values should stay null for both maps, too:
neither of the maps is used outside of JavaSE case - no reason to
always initialize them.
Again, PersistenceProvider and the Gemini code is not JavaSE, it's
multi-threaded OSGi. It's easier to initialize them statically
which is thread safe than to write multi-thread aware initialization
code.
Even in JavaSE case initialPuInfos only used if the javaagent is
used -
initializing it application managed case on app. server would mean
that
changes made to redeployed persistence unit would be ignored.
Gemini provides an OSGi "Agent" that may run multiple times for
different bundles to perform initialization and support weaving.
But could you clarify the issue with redeployment?
Shaun
On 12/07/2010 3:15 PM, Shaun Smith wrote:
Bug 312947 - Allow
EclipseLink JPA to work with Gemini in OSGi
https://bugs.eclipse.org/bugs/show_bug.cgi?id=312947
Minor adjustments to JPA initialization to work with Gemini
JPA. This
revised patch does not remove what seemed to be dead temploader
code as
James advised is still necessary to support weaving legacy apps
using
sessions.xml.
--
Shaun
Smith | Principal Product Manager
Phone: +19055023094
Oracle Server Technologies,
Oracle
TopLink
ORACLE Canada | 110 Matheson Boulevard West, Suite 100,
Mississauga,
Ontario | L5R 3P4
Oracle
is committed to developing practices and products that help
protect the
environment
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
--
Shaun Smith | Principal Product Manager
Phone: +19055023094
Oracle Server Technologies, Oracle
TopLink
ORACLE Canada | 110 Matheson Boulevard West, Suite 100,
Mississauga, Ontario | L5R 3P4
Oracle is committed to developing practices and
products that help protect the environment
|