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: Integrating Autofetch with OpenJPA
Date Tue, 11 Mar 2008 21:16:04 GMT
Hi Ali,

On Mar 11, 2008, at 11:10 AM, Ali H. Ibrahim wrote:

> Hi,
> The way I deal with serializability right now is to make the  
> tracking state in entities/proxies transient which seems reasonable  
> since the tracking is a performance optimization and profiler is  
> local.

I agree it seems reasonable to add a transient variable to use for the  
> The main issue is that callbacks for entities / collections is not  
> enough. In each entity / collection I need to store a reference to  
> the tracking object used to record accesses. I also need to monitor  
> when the entity is actually used for the first time by the program;  
> this is not the same as whether it is lazily instantiated since I  
> want to monitor access to entities that are already loaded. I was  
> hoping that it would not introduce too much overhead since the  
> enhanced entities are already instrumented for lazy access?

Ideally, the overhead for the tracking implementation is low enough to  
run in production, so a real system can dynamically tune itself. That  
would be a real win: install this jar, restart your server, and watch  
the system improve performance all by itself.
> The perfect hook would be to able to modify the enhancing process.

That's certainly an option that you can look into.

The other approach would be to use an IdentityMap of object to  
tracking object that you maintain yourself. When you get a callback,  
see if the object is already being tracked, and if not, create one and  
add it to the map. That's basically how the persistence context works  



> Regards,
> Ali
> Craig L Russell wrote:
>> Hi Ali,
>> There are a number of interesting things that we can do with this  
>> technology, and I'd like to explore them.
>> On Mar 10, 2008, at 10:05 AM, Ali H. Ibrahim wrote:
>>> Hi,
>>> I am interested in writing a connector for OpenJPA and Autofetch.  
>>> Autofetch is an open source project I am working on (

>>> ) which automatically specifies fetch plans for queries. The basic  
>>> approach is to monitor the traversal of query results and "learn"  
>>> the right fetch plan when you execute similar queries in the  
>>> future. The query result type as well as the program stack is used  
>>> to identify queries and distinguish between query invocations in  
>>> different contexts. The Autofetch web page has an example of the  
>>> software engineering benefits of this approach in addition to the  
>>> simplicity of not having to specify fetch plans. I already have a  
>>> Hibernate connector which works pretty well.
>>> What I am looking for is the appropriate extension points (if  
>>> available) to perform the integration with OpenJPA:
>>> 1. I need to intercept entity property accesses (either via field  
>>> or getter access). I need to be able to do this for proxies as  
>>> well as instantiated entities.
>> A callback from StateManager would probably work best here. One  
>> thing I'd worry about is performance. Calling back a listener on  
>> every field access might be bad, so I'd like to see how to reduce  
>> the impact. Perhaps establish an algorithm in which the callback is  
>> only invoked for every 1000 calls?
>>> 2. I need to be able to store some state in proxies / enhanced  
>>> entities and have them implement an additional interface.
>> This needs a bit more detail. OpenJPA would have to instrument the  
>> entity differently. And implementing an additional interface and  
>> field impacts serializability.
>>> 3. I need to intercept lazy collection instantiation.
>> A StateManager callback is probably the best thing for this.
>>> 4. I need to be able to store some state in a collection  
>>> associations whether they have been instantiated yet or not.
>> We already know this. The internal API could be used instead of  
>> your own extra field.
>>> 5. I need to be able to create a fetch plan dynamically for  
>>> queries, finds, etc. I think this is already pretty  
>>> straightforward in OpenJPA (even easier than Hibernate).
>> This is a good idea, and a callback from the query processor might  
>> be the approach.
>> Let's discuss in some more detail.
>> Craig
>>> For Hibernate, I was able to get points 1,2 by createing a custom  
>>> "tuplizer" which handles instantiating and proxying entities.  
>>> Points 3,4 were harder and required hacking around the  
>>> configuration although I was able to do it without duplicating  
>>> much code and without forking the codebase. Point 5 was taken care  
>>> of by creating custom load listeners and wrapping criteria  
>>> queries, although I have not figured out how to deal with HQL  
>>> queries.
>>> Any help is appreciated.
>>> Regards,
>>> Ali Ibrahim
>> Craig Russell
>> Architect, Sun Java Enterprise System 
>> jdo
>> 408 276-5638
>> P.S. A good JDO? O, Gasp!

Craig Russell
Architect, Sun Java Enterprise System
408 276-5638
P.S. A good JDO? O, Gasp!

View raw message