You are here: Basics Operations & Concepts > Activation > Transparent Activation > TA Implementation

TA Implementation

The basic idea for Transparent Activation:

With Transparent Activation the user does not have to worry about manual activation at all. Activatable objects will be activated on demand. Objects that do not implement Activatable will always be fully activated.

The basic sequence of actions to get this scheme to work is the following:

  1. Whenever an object is instantiated from db4o, the database registers itself with this object. To enable this on the database level TransparentActivationSupport has to be registered with the db4o configuration. On the object level an object is made available for TA by implementing the Activatable/IActivatable interface and providing the according bind(activator) method. The default implementation of the bind method stores the given activator reference for later use. Note, that only one activator can be associated with an object: trying to bind a different activator (from another object container) will result in an exception. More on this in Migrating Between Databases.
  2. All methods that are supposed to require activated object fields should call activate(ActivationPurpose)/Activate(ActivationPurpose) at the beginning of the message body. This method will check whether the object is already activated and if this is not the case, it will act depending on which activation reason was supplied.
  3. The ActivationPurpose can be READ or WRITE. READ is used when an object field is requested for viewing by an application. In this case Activate method will request the container to activate the object to level 1 and set the activated flag accordingly (more on this case in the following chapters). WRITE activation purpose is used when an object is about to be changed; a simple example is setter methods. In this case the object is activated to depth 1 and registered for update. More on ActivationPurpose.Write in Transparent Persistence.

This implementation requires quite many modifications to the objects. That is why db4o provides an automated TA implementation through bytecode instrumentation. With this approach all the work for TA is done behind the scenes.

Automatic and manual TA approaches are discussed in detail in the following examples.