Re: Fetch notifications

[Matthew Adams <ma...@matthewadams.me>]

inline...

On Sat, Mar 28, 2009 at 4:33 AM, Andy Jefferson <an...@datanucleus.org> wrote:
> By "tuning", are you proposing addition of non-fetchplan fields to the
> selected fetch plan, or are you also proposing removal of "unused" fields
> from the selected fetch plan?
>
I had only explicitly considered the addition of fields that hadn't
been loaded, but it could be used to prevent over-loading (loading
more than is necessary for the given use case).  Me likey.

> If the proposal includes the removal of unused fields from the fetch plan then
> the listener would need to be on any jdoGetXXX/jdoPutXXX calls (rather than
> when something was loaded). So would be an AccessListener - do we need to
> distinguish between user read and user write of a field for this? Dont think
> so.
>
Yes, it would need to be on all jdoGet/jdoPut calls.  As I mentioned
in my previous email, I think a nice, general StateManagerListener
would be best.  Let a listener listen to anything it wants to -- no
need to limit them.

> Presumably somewhere the fetch plan is being updated as a result of the fetch
> notifications, so a new fetch group is added "AUTO" with the fetched fields
> in ?
>
That would be nice, but I think that begins to step beyond what the
spec should mandate.  The spec could suggest this, but I think that
should be as far as it goes.

> Who does the "tuning" ? The implementation ? Something generic in
> JDO(Impl)Helper?
>
I'm thinking that we could write an implementation that is not part of
the specification deliverables but that is part of the Apache JDO
project.  The initial idea would be to register it as a listener and
then, after the use case has been exercised (during integration or
performance testing), the listener could be interrogated for what it
would recommend for fetch plans.

>
> Re: UseCase
> +1 to the general idea. Needs definition of what is in scope for inclusion in
> the "use-case". Obviously current PM props
> ("multithreaded", "detachAllOnCommit", "IgnoreCache", "queryTimeoutInMillis", "copyOnAttach", "fetchPlan")
> and current Transaction props (optimistic, nontx-read, nontx-write,
> restoreValues, retainValues, txnIsolationLevel, txnRollbackOnly) and also
> extensions.
>
Yes, we would have to define what's in scope.  I agree on most of
these, but I was a little surprised by multithreaded -- I suppose it's
performance related, but I always thought of it more as a functional
thing.  Maybe it's the gray area between the two.  Specified
transaction properties are definitely candidates for inclusion in use
case definitions.  One thing that I would expect to be an extension in
almost every implementation would be locking semantics.  JDO doesn't
really deal much with locking directly, but the implementations do.
Maybe JDO could define the 4 standard, loosely-defined semantics
(SERIALIZABLE, READ_COMMITTED, REPEATABLE_READ, READ_UNCOMMITTED) for
the purposes of use case definition.

> Is the use-case definable solely in XML ? or perhaps we have an API too.
>
I would expect the primary manifestation to be in metadata outside the
code (XML or otherwise).  I suppose we could have an API for
completeness, but I'm curious as to how API-based use cases would be
utilized.

> Is there only one use-case active and beginUseCase() removes any previous ?
>
Correct.  One use case active at a time, and yes, a begin without a
prior end would implicitly end the previously active use case.  An
explicit end call would end whichever use case was currently active,
and be a no-op if no use case were currently active.

> I'd probably prefer
> PM.setUseCase(String name);
> PM.unsetUseCase();
>
Pot-AY-toes, pot-AH-toes.  To have a bean-style property "useCase" on
PM (& PMF) seems intuitive.  I might require that if useCase is set to
null or the empty string, it effectively stops using the current use
case settings, and I would implement unsetUseCase as a convenience
method:  public void unsetUseCase() { setUseCase(null); }.

-matthew