You are here: Basics Operations & Concepts > Transparent Activation/Persistence > Transparent Activation Pitfalls

Transparent Activation Pitfalls

Transparent Persistence is a powerful feature that can make your development much faster, easier and more error-proof. However 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 lead to unexpected and undesired results.

Not Activate Call Before Field Access

Before accessing any field you need to call the activate-method. This is true for all getter/setter and also for other methods like the toString-method. The best strategy is to call the activate-method in the getter/setter and then access the field through those even in the class itself.

Or use the enhancement-tools to avoid this issue complete.

Migrating Between Databases

Problem

Transparent Activation is implemented through the Activatable-interface, which binds an object to the current object container. When an object is stored in more than one object container, this logic won't work, as only one binding is allowed per object.

Solution

To allow correct behavior of the object between databases, the object should be unbound before being stored to the another database.Just set the activator to null.

Instrumentation Limitations

Problem

For Java built time enhancement the classes to instrument should be on the classpath.

Solution

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

Debugging Instrumented Classes

Debugging instrumented classes may not work 100% correct. Make sure that you are using the debug-flag for the db4otool

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.