You are here: Usage Pitfalls > Transparent Activation

Transparent Activation

Transparent Activation is a powerful feature that can make development much faster, easier and error-proof. But as any power it can lead to trouble if used in a wrong way. The aim of this chapter is to point you out to typical pitfalls, which can lead to unexpected and undesired results.

Not Activatable Objects

Problem

When TA is enabled Activatable objects are activated transparently on request, whereas not Activatable objects are fully activated. This is done to keep consistency in persistent objects behaviour. However, there is a potential danger of activating too many unnecessary objects and wasting system resources. You will experience lower performance and in the worst case you can end up with OutOfMemory error.

Solution

Make all persistent objects Activatable. This can be done through using load time (Java only) or build time Transparent Activation Enhancement. For more information see Transparent Activation Framework documentation.

Collections Activation

Problem

Current implementation of TA Framework does not support lazy activation of collection members, i.e. the whole collection will be activated as one object on the first request. However, this only applies to collection object itself, i.e. Activatable members of the collection will be activated in a transparent way.

Solution

Use db4o proprietary collections: com.db4o.collectections package in Java and Db4objects.Db4o.Collections in .NET

Migrating Between Databases

Problem

Transparent Activation is implemented through Activatable/IActivatable interface, which binds an object to the current object container. In a case when an object is stored to more than one object container, this logic won't work, as only one binding (activator) is allowed per object.

Solution

To allow correct behavior of the object between databases, the object should be unbinded before being stored to the next database. This can be done with the following code:

Java:

myObject.bind(null);

For more information see an example.

Instrumentation Limitations

Problem

For Java instrumentation instrumenting classloader must know the classes to instrument, i.e. all application classes should be on the classpath.

Solution

Make sure that all classes to be instrumented are available through the classpath

Debugging Instrumented Classes

Problem

Debugging instrumented classes may not work 100% correct both on Java and .NET. Some of the observed problems:

Solution

You should be able to debug normally anywhere around instrumented bytecode. If you still think that the problem occurs in the instrumented area, please submit a bug report to db4o Jira.