You are here: Usage Pitfalls > Dangerous Practices

Dangerous Practices

Db4o databases are well protected against corruption. However some specific configurations can make your database file vulnerable.

  1. Configuration#lockDatabaseFile(false)

    Java platforms before JDK1.4 do not prevent concurrent access to a file from different JVM. If database file locking is turned off on these platforms, concurrent write access to the same database file from different JVM sessions will corrupt the database file immediately. Do not use this setting unless your application logic guarantees that only one VM session can access your database file at a time. For more information see No lock file thread.

  2. NonFlushingStorage

    In order to ensure ACID transaction db4o uses a special strategy, which relies on the order of writes to the storage medium. On operating systems that use in-memory file caching, the OS cache may revert the order of writes to optimize file performance. db4o can enforce the correct order by flushing file buffers after every step of transaction commit. Turning this setting off puts you in potential danger of data corruption if a system or hardware failure occurs during commit.

  3. The following refactorings are incompatible with db4o:
    1. Adding classes within a class hierarchy or above a class hierarchy. Example:

      Original --------------
      class A
      class B extends A
      Refactored ------------------
      class A
      class C extends A
      class B extends C

    2. Removing a class from the top or within a class hierarchy. Example:
      Original --------------
      class A
      class B extends A
      class C extends B
      Refactored ------------------
      class A
      class C extends A
    3. Changing the type of a field to be an array or back. Example:
      Original --------------
      class Foo { String bar; }
      Refactored ------------------
      class Foo { String [] bar; }
If you apply such a refactoring, you will not be able to read existing objects correctly.

More information on refactorings see Refactoring and Schema Evolution