An interesting side effect of the suggested JDO-JPA bridge is that JDO gets
Java EE integration for free! Spring supports JDO but probably EJB based
application servers will never do (at least directly).
But look at this:
@Stateless
public class EmployeeServiceBean {
@PersistenceContext(unitName="MyUnit") JEntityManager pm;
public void addEmployee(String name)
{
Employee employee = new Employee(name);
pm.makePersistent(employee);
}
:
:
}
This is even better than the EntityManager's getDelegate hook method. Similar
injection can be used also for JEntityManagerFactory when necessary. I just
hope that a field that is annotated with @PersistenceContext can be of a
subtype of EntityManager (if not an additional field and a casting in a
@PostConstruct method might be needed, maybe this can be inherited and
implemented once for the entire project).
Notice that also JDO implementations with no full JPA support can gain from
this by implementing JEntityManager and the other new interfaces and throwing
NotSupported exceptions in most JPA methods. Only support for initialization
from persistence.xml file and a few JPA methods is required (very simple) . Of
course, such an implementation is not expected to claim for
"javax.jdo.option.JPA" support.
It seems that the new pluggable provider architecture of EJB 3.0 can work great
for JDO!
----- Original Message -----
From: Ilan Kirsh
To: [email protected] ; JDO Expert Group
Sent: Saturday, October 07, 2006 8:08 PM
Subject: A JDO-JPA Bridge
Hi all,
Following is an enhancement suggestion for JDO 2.1 (or maybe even for JDO
2.01?) that may give maximum results in minimum effort.
I suggest to add four new interfaces to javax.jdo (or to a sub package):
public interface JEntityManagerFactory extends
javax.persistence.EntityManagerFactory,
javax.jdo.PersistenceManagerFactory
{
}
public interface JEntityManager extends
javax.persistence.EntityManager, javax.jdo.PersistenceManager
{
}
public interface JEntityTransaction extends
javax.persistence.EntityTransaction, javax.jdo.Transaction
{
}
public interface JQuery extends
javax.persistence.Query, javax.jdo.Query
{
}
JDO 2.1 Implementations that will support the new optional
"javax.jdo.option.JPA" feature will have to return instances of these
interfaces instead of the super interfaces when using either the JDO API or the
JPA API.
For instance, a JDO 2.1 implementation with JPA 1.0 support will support
datastore transactions (currently only optimistic transactions are supported by
JPA):
EntityManagerFactory emf =
Persistence.createEntityManagerFactory("myUnit");
EntityManager em = emf.createEntityManager();
((JEntityTransaction)em.getTransaction()).setOptimistic(false);
And will support using Extent (no Extent in JPA and I think that there is no
support for filtering subclasses, at least not in an easy way):
EntityManagerFactory emf =
Persistence.createEntityManagerFactory("myUnit");
EntityManager em = emf.createEntityManager();
Extent extent = ((JEntityManager)em).getExtent(MyClass, false);
As well as many other things that are missing in JPA, for example:
boolean isDirty = JDOHelper.isDirty(entity);
EntityManager em = (EntityManager)JDOHelper.getPersistenceManager(entity);
These examples are for using JPA with JDO extensions which I think is more
interesting. Of course, similar examples can be written also for the other
direction (using JPA from JDO).
The names of the new four interfaces is based on the JPA interface names in a
way that may suggest that they are more powerful. Which do you consider more
powerful AWT Frame, Panel and Button or Swing JFrame, JPanel and JButton? If
JPA will catch then every curious Java developer will soon know that there is
EntityManager but there is also JEntityManager that supports additional
operations and unlike Hibernate or TopLink extensions is supported by many
vendors and backed by a standard! I agree with David that some day the majority
of the JPA implementations might be also JDO implementations. In that case,
JEntityManagerFactory, JEntityManager, JEntityTransaction, JQuery, JDOHelper
and Extent may be something significant that cannot be ignored in the JPA
market.
The minimum that is required in order to support this addition in JDO 2.1 is:
- Adding the four new interfaces.
- Adding "javax.jdo.option.JPA" to the specification with a short explanation.
Actually the maximum is not so far from the minimum:
- New section in the specification that explains this addition with more
details and maybe some examples.
- Handling possible conflicts (e,g, which exceptions are thrown JDO or JPA?).
- TCK tests that check that an implementation that claims to support
"javax.jdo.option.JPA" indeed returns instances of the new four interfaces.
Of course, no need to describe the JPA in the JDO spec or write JPA tests
because all this is already handled by the EJB 3 spec.
Accepting this suggestion will enable using JDO in two modes:
1. Standalone (for current users as well as for new users that are
interested).
2. As an extension to JPA (might be very useful if JPA will catch).
Any comments will be welcomed.
Regards,
Ilan Kirsh
ObjectDB Software
http://www.objectdb.com
