db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Adams <matt...@matthewadams.me>
Subject Fetch notifications
Date Fri, 20 Mar 2009 22:58:34 GMT
Hi all,

Sorry for the delay on this.  This is pursuant to my action item:
> [Feb 13 2007] AI Matthew discuss on email method by which an application
> might dynamically tune itself by tracking field access by use-case?

Overview

Currently, the only standard means to tune JDO applications is via
source code modifications, particularly via fetch plan functionality
offered by PM and vendor-specific APIs.  IMHO, performance tuning
could and should be addressed outside of the source code; it is a
concern orthogonal to the application's functionality, much like
persistence itself is to the domain objects.  The impetus behind these
proposals, then, is to allow for performance tuning capabilities to
take effect outside of code, or to provide JDO users or tooling
information on performance-related aspects, so that after performance
analysis, the data collected could be easily used to define fetch
groups that are use case-specific.  Since the only JDO standardized
performance tuning feature that I could see is the fetch plan, I will
start there (solution A below) and progress to a more general solution
(B & C below).  These are only food for thought; I'm hoping that the
input from others will help standardize performance tuning features
commonly available among implementations.

Solution A:  FetchListener

My first thought, which doesn't consider the notion of "use case", was
to define an interface an implementation of which could register
itself with the PM/PMF that would be notified when a given field of a
given object was loaded.

For example,

public interface FetchListener {
  void onFetch(FetchEvent event);
}

public class FetchEvent {
  Object getInstance() {...} // returns the PC whose field was fetched
  Class getInstanceClass() { return getInstance().getClass(); }
  String getInstanceClassName() { return getInstanceClass().getName(); }
  Field getField() {...} // returns the Field object for the field
being retrieved
  String getFieldName() {...} // returns the name of the field being retrieved
  Object getFieldValue() {...} // returns the value of the field being retrieved
  String[] getFetchGroups() {...} // returns the name(s) of the fetch
group(s) currently in use, or an empty array if none
}

// mods to PersistenceManager
public interface PersistenceManager {
  ...
  void addFetchListener(FetchListener fl);
  void removeFetchListener(FetchListener fl);
  ...
}

The spec itself would not necessarily provide a default implementation
of FetchListener, but I could see the Apache JDO project providing a
convenient, configurable FetchListener implementation that could be
interrogated for the fields accessed during the PM's use so that a
fetch group could be easily obtained, named, and added to the JDO
metadata by the developer.

Solution B:  StateManagerListener
Next, I considered instead a more general solution that would use the
StateManager interface and the idea of a StateManagerListener, with
notifications for each applicable method on the StateManager.

For example,

public interface StateManagerListener {

  void onGetBooleanField(StateManagerEvent event);
  void onGetByteField(StateManagerEvent event);
  ...
  void onProvidedBooleanField(StateManagerEvent event);
  void onProvidedByteField(StateManagerEvent event);
  ...
  void onReplacingBooleanField(StateManagerEvent event);
  void onReplacingByteField(StateManagerEvent event);
  ...
  void onSetBooleanField(StateManagerEvent event);
  void onSetByteField(StateManagerEvent event);
  ...
}

public class StateManagerEvent event {
  ... // TBD, but probably similar to FetchEvent
}

Solution C:  JDO Use Case
Introduce a new concept to JDO called "use case" that encompasses
exclusively performance-tuning related features, including an
extension mechanism so that tuning features that aren't specified can
still be supported.  This design is similar to Xcalia's use case
support.  It would look something like the following:

// mods to PersistenceManager
public interface PersistenceManager {
  ...
  void beginUseCase(String useCaseName); /* named performance tuning
settings in metadata (fetch plan, locking, optimistic txns, etc) would
be set and used */
  void endUseCase(); /* unsets the current use case's settings; no-op
if no current use case */
  ...

UseCase could also be a standard PMF property of type String that
would hold for all PMs obtained from the PMF, which would allow use
case-specific PMFs and no need for a user to call the
beginUseCase/endUseCase methods programmatically.

Let's kick it around!

-matthew

Mime
View raw message