Thursday, February 4, 2010
Enterprise OSGi does not make JPA more dynamic
I just browsed the draft version of the new OSGi specs for the enterprise. I was especially interested in how they want to address the JPA related problems. They have not chosen a fundamentally different path than I've been doing JPA development in OSGi for 2 years now. Difference is, they propose a new interface (PersistenceUnitProvider) to be registered for each persistence unit while I was just registering an EntiyManagerFactory with the "pu-name" service property. So every interested service could directly bind to a specific EntityManagerFactory and create its EntityManager from it. So far so good.
I was surprised however, that the OSGi specs do not address the main issue with JPA. It's static. You can not add/remove entities dynamically. It was never designed that way and the OSGi enterprise will not solve that issue. You still have to specify all entities up front in the dreaded persistence.xml. Yet, the more OSGi way would be to skip that file altogether, have the name of the persistence unit name as service property (unit.name) of the PersistenceUnitProvider and let the PUP consume entity beans (exported as java.lang.Object services) with their "unit.name" specifying their target unit. The PersistenceUnitProvider would then have to parse the beans annotations and incorporate it into its EntityManagers.
I am aware of the big problems that can bring with it. What if there are currently transactions running? Does removing an entity from the system also mean to clean up the database? The JPA implementation would have to rebuild its internal state and caches on entity changes. I had hopes the OSGi enterprise spec would address those issues of non-dynamically of current JPA implementations.
So even with this new spec, not much is going to change how I program JPA. It will still not be possible to add new business logic to a running OSGi system without touching the persistence.xml.
Subscribe to:
Post Comments (Atom)
The primary goal of the OSGi JPA spec is to enable the programming with JPA in OSGi and not to add new features to the core JPA spec, this is the prerogative of the JCP.
ReplyDeleteThat said, I am afraid you probably are looking at some outdated information. In the last few months we've worked hard to address some of the dynamics related to multiples of providers, persistence units, and versions. In the processed we changed the API drastically. The spec detailing this is currently out for member vote and will very likely be available during OSGi DevCon/EclipseCon in March. Though we did not add dynamic entity management, I do think the model allows you to handle multiple units of business logic that can be independently updated. Though it might require a bit of planning.
Peter Kriens
Philip,
ReplyDeleteyou're right - thats exactly the pain of using JPA in OSGI Enterprise applications. doesn't matter if using eclipse link or easy beans or so.
Peter,
I'm looking forward to EclipseCon/OSGI DevCon in march to see what will be possible with OSGI for the Enterprise.
ekke
Perhaps you should have a look into the Java Data Objects(JDO) 2.x spec. JDO was designed since the beginning to allow dynamic deployment of additional persistent classes as it nevers requires to enlist all used persistent classes during PersitenceManagerFactory( the JDO EntityManagerFactory ) startup. If you are lucky you may find a JPA implementation which also offers JDO capabilities like Datanucleus or OpenJPA.
ReplyDeleteThanks for your comment Peter. I am aware of that OSGi cannot change the way JPA works. I just hope that when OSGi gets more adopted in the "Enterprise" world, the JPA spec will make some progress too.
ReplyDeleteLooking forward to the updated spec.
I will also take a look into JDO.
With Entity classes they are most often linked via relationships (OneToMany, ManyToOne etc) to other entity classes.
ReplyDeleteSo when you "add an entity class" you really need to add all the entity classes that relate to it (to honour those relationships) ... and all entity classes that relate to those ones etc etc.
> The JPA implementation would have to rebuild its internal state and caches on entity changes.
Yes, but that is not all. The JPA implementation holds meta data on the relationships (for cascading persistence, parsing and executing queries, lazy loading etc).
Aka, registering new entity classes means that the relationship meta data held by the ORM also needs to be rebuilt.
Aka, this means the EntityManagerFactory needs to be 'reinitialised' which is generally not a low cost operation (but hopefully not too expensive either).
Is it not reasonable just to re-initialise the EntityManagerFactory?
Do you know of some solution to this?
Cheers, Rob.
Disclaimer: I'm a developer of Ebean ORM which is similar to JPA (uses JPA mapping but has a session-less api - aka no merge/flush etc).
Yes I know about the relationship tree in JPA. It's also not a problem if rebuilding the EntityManagerFactory would take some time. After all, that would not happen often. The first thing to improve on, would be that you would be able to feed the entities to persistence units from multiple bundles. Currently that is not possible. However in a perfect OSGi world thats how it would happen.
ReplyDeleteDataNucleus is compliant with OSGi since its beginning and it's allow registering classes dynamically at runtime.
ReplyDeleteThere is no need to recreate EMF to register new classes, however modifying existing classes requires transaction completion or flush of changes, since these classes are strong referenced by the transaction manager.