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.
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?
The perfect hook would be to able to modify the enhancing process.
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
(http://www.cs.utexas.edu/~aibrahim/autofetch) 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 http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
