Hi,
Comments inline.
Craig L Russell wrote:
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.
That is definitely the goal of Autofetch. Although I would argue the
real win in a serious application is the improving the modularity of
the program, because good engineers will specify the right prefetch
specifications manually. It is nice that it makes it easier for
programmers as well. I think that we should not worry too much about the
performance of the enhanced entities. In general query performance
dominates any performance considerations due to proxies. Of course, we
can do a variety of tricks to lower overhead some of which you mentioned
like sampling.
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
today.
Yes, this is an option as well. The downside is that you have to hook
into the session lifecycle to make sure you don't leak memory. I will be
taking a closer look at the code in the next couple of days and I might
be able to ask better questions then...
Regards,
Ali Ibrahim
