openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <>
Subject Re: unenhanced class support
Date Fri, 20 Jul 2007 19:07:27 GMT
First off, this sounds great!  From various discussions I've had with
customers moving off of Hibernate to OpenJPA, our enhancement process is
always a topic.  I can usually convince them that the enhancement process is
not that bad, but for the initial out-of-the-box experience, it would be
great to skip this step.

Given that, if we are going to allow OpenJPA to work with unenhanced
classes, we probably need to decide what the goal is.  If we are doing it
just for the initial out-of-the-box experimentation, then I don't see where
performance should be a concern.  It sounds like we can provide similar
levels of functionality, but with a performance cost.  That should not be
that big of a deal.  We can explain that better performance and other QOS
can be had with pre-enhancing the classes.

But, if our goal is to compete with Hibernate with unenhanced classes, then
it sounds like we have lots more work to do.  But, is it worth the cost and
effort?  No "real" bake-off happens with out-of-the-box products.  There are
always configuration tweaks that help the product's performance.

I would think that getting the unenhanced classes to work with OpenJPA
should be our priority, with the performance concerns being secondary.  From
your notes, it sounds like you have a good idea on how to accomplish the
"missing functions", but they may introduce some performance overhead.  From
my perspective, that should be okay.

Thanks for experimenting with this!

On 7/20/07, Patrick Linskey <> wrote:
> Note that there actually is another option for handling instances for
> which we can't track field mutation: we can just always do an UPDATE
> with all the fields in the instance, regardless of whether there was a
> change.
> Also, I actually have some of the code necessary to do field
> comparison already written, so we should try to figure out what the
> right decision is, regardless of implementation cost, at least
> initially.
> -Patrick
> On 7/20/07, Patrick Linskey <> wrote:
> > Hi,
> >
> > Over the last week, I've been working on making OpenJPA work with
> > unenhanced classes in a variety of different environments. My goal has
> > been to make the enhancement step (either at build time or via the
> > javaagent) optional in order to remove a barrier to entry for
> > newcomers to OpenJPA. There are still reasons why enhancement is a
> > good thing to do in a running OpenJPA system, but my hope is that we
> > can make these be mostly quality-of-service issues, and not
> > functionality issues.
> >
> > I've been pretty successful so far, but there are a few limitations in
> > some environments. I'd like to get some feedback about what to do
> > about these limitations. First, I'll describe my approach:
> >
> > I started looking into this when Marc told me about the new
> > retransformation capabilities in Java 6. (Briefly, in Sun's Java 6
> > impl, it is no longer necessary to specify a javaagent flag in order
> > to retransform classes.) This led me to investigate retransforming
> > entity types to add field-tracking code to method blocks without
> > violating any of the retransformation rules. I combined this with a
> > subclassing approach so that instances created by OpenJPA (vs. created
> > by the user with 'new') can be treated as proper persistence-capable
> > instances.
> >
> > Since retransformation does not allow fields, methods, or interfaces
> > to be added to a class, I added a helper class that maintains a static
> > map of *all* the instances created with 'new' that have been
> > persisted; this map associates a managed instance with a
> > ReflectingPersistenceCapable instance, which implements
> > PersistenceCapable via reflection, as the name implies, and can wrap
> > unenhanced managed instances for OpenJPA's needs.
> >
> > So, the only functionality cost in a Java 6 environment is the extra
> > overhead of occasionally looking up the PersistenceCapable for a given
> > unenhanced managed instance. There is still a bit of a performance
> > cost, since I needed to do reflection in some places instead of direct
> > field access because of details of the class hierarchy and field
> > access restrictions.
> >
> > In a Java 5 environment, if you specify a new javaagent class, then
> > the situation is exactly the same. IMO this improves on our current
> > javaagent in that it releases the restriction that persistent types
> > must be listed in the first persistence unit in persistence.xml, and
> > because the redefinition logic is never invoked against any
> > non-managed types.
> >
> > If you do not specify a javaagent class in Java 5, then OpenJPA cannot
> > do redefinition. However, it can still create subclasses with logic in
> > overridden setters and getters. So, in Java 5 without a javaagent but
> > with property access, we only lose dirty tracking and lazy loading for
> > instances created by  the user code. This only matters for cases where
> > an instance so created is flushed (for dirty tracking) or cleared (for
> > lazy loading).
> >
> > In Java 5 without a javaagent and with field access, things are a bit
> > worse -- OpenJPA can't do any dirty tracking or lazy loading, either
> > for instances created by the user code or for instances created by
> > OpenJPA.
> >
> > We could improve the situation a bit for field access and post-flush
> > property access in Java 5 with no javaagent. This would require state
> > comparison, though, which is not the fastest thing in the world, and
> > requires that we hold hard references to all applicable instances for
> > the duration of the EM's life (all user-created property access
> > instances, and all field access instances regardless of how they were
> > created).
> >
> >
> > So, I'm looking for answers to the following questions in particular:
> >
> > 1. what should we do about { Java 5, no javaagent, field access }?
> > Should we support this configuration, including the corresponding
> > extra overhead, or should we require either property access or a
> > javaagent specified in these configurations?
> >
> > 2. what should we do about { Java 5, no javaagent, property access,
> > flushed | cleared instances }? There is a much lower impact to doing
> > the dirty tracking in these configurations, since the scope is
> > narrower. However, we might also be able to just not allow flush or
> > clear or multiple sequential transactions if the persistence context
> > has references to unenhanced, unredefined user-created instances.
> >
> > Thoughts?
> >
> > (Oh, and the code is still a work in progress -- everything I
> > discussed above is working, but serialization and cloning and
> > detachment are untested, and will probably require some tweaks to get
> > working correctly.)
> >
> > -Patrick
> >
> > --
> > Patrick Linskey
> > 202 669 5907
> >
> --
> Patrick Linskey
> 202 669 5907

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message