openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: unenhanced class support
Date Sat, 21 Jul 2007 00:28:32 GMT
Hey,

On Jul 20, 2007, at 12:07 PM, Kevin Sutter wrote:

> Patrick,
> 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.

I agree. I've suffered through people always asking why enhancement  
is required, and even though there is a significant performance  
advantage to be had, they grumble.
>
> 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.

I think this should be the #1 goal.
>
> 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.

We should be prepared to match Hibernate's performance features,  
feature-for-feature. As a longer term objective, it will be nice to  
compete head-on with Hibernate, but by the time we get there,  
Hibernate will be competing with OpenJPA with an enhanced version. So  
if customers compare unenhanced Hibernate vs. OpenJPA and then  
enhanced Hibernate vs. OpenJPA, I'd rather we spent our energy on  
enhanced performance.

Craig
>
> 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!
> Kevin
>
> On 7/20/07, Patrick Linskey <plinskey@gmail.com> 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 <plinskey@gmail.com> 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
>>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message