Just a brief summary on the status quo and future plans for TA...

What's it all about? Simple: Whenever an object's state is accessed directly or indirectly for the first time, db4o should activate its fields.

db4o cannot observe field access on arbitrary objects, so it has to rely on notifications from the objects themselves. This capability can be implemented with handcrafted code or via bytecode instrumentation. The design choice of the "notification API" boils down to "activate()" (one activator per persistent object) or "activate(this)" (one activator per database). We have chosen the "activate()" flavor, as appropriate objects for this role have been around, anyway: the weak references db4o keeps for "alive" objects. This makes for two interfaces so far:

Activator
  activate()

Activatable
  bind(Activator)

Whenever db4o instantiates a persistent object implementing Activatable, it will call #bind() with the corresponding weak reference holder as an argument. Then it will just rely on #activate() calls being triggered from the object.

This is all it needs to handcraft TA aware classes. However, manually cluttering all persistent classes with activator fields and #activate() calls is not an option - enter code instrumentation.

Starting with an optimistic, "closed world" assumption that we can instrument any class we want, how can we inject TA awareness? Naively, we can scan for all field access instructions and inject an #activate() call to the corresponding activator. (Variants of this pattern include instrumenting the beginning of every method call, etc.) Simplified:

public class Foo {
  private int _x;
  public int bar(Foo foo) { return _x + foo._x; }
}

=>

public class Foo implements Activatable {
  private int _x;
  private Activator _activator;
  public void bind(Activator activator) { _activator = activator; }
  public void activate() { _activator.activate(); }
  public int bar(Foo foo) {
    this.activate();
    foo.activate();
    return _x + foo._x;
  }
}

Basically that's it, notwithstanding lots of possible optimizations. But of course the closed world assumption doesn't hold. We have to find out which classes to instrument and how to handle the others.

For the time being we'll assume that we have a list of (persistent) classes to be instrumented. However, we may not be able to make them TA aware in all cases - a class with public fields may always have non TA aware clients, there's classes extending JDK platform classes that must not be instrumented,... If persistent classes fail to meet the requirements, they must not be instrumented and appropriate diagnostic warnings must be issued.

The easiest way to handle non TA aware objects correctly is to simply activate them. db4o in TA mode then basically would work like it would with an infinite activation depth - until it encounters a TA aware object, where it gains control again.

Of course this is not an option for ubiquitous, performance-intensive objects like basic collections. In a first step we will provide custom, TA aware implementations for common collections like ArrayList, HashSet, etc. Upcoming db4o optimized fast collection implementations will support this mechanism, too, of course. (Optionally one could think of using these implementations as drop-ins for completely db4o unaware classes using the collection interfaces only, but this approach comes with its own bag of disadvantages.)

For the implementation, we will stick to the bytecode mangling libraries we have already been using for native queries analysis and generation: Cecil for .NET and Bloat for Java. Instrumentation should either occur at load time, or at build time for those who want to avoid distributing the bytecode libs along with their application.

The current state is available in the db4ota, db4otaj and db4o.net/Db4objects.Db4o.TA folders from our repository.

So that's the plan: Provide a minimal public API for hooking into the TA mechanism. On top of it, provide a mechanism to instrument persistent classes at build time or load time as described above. Provide special handling for important platform classes and fallback behavior for non TA aware classes. Ensure and encourage interoperability with 3rd party handcrafted or automagically instrumented classes.

But as with all plans, this one still may be subject to changes. If you would like to participate in further development in terms of design choices and implementation details, please join discussion in the developer forum.