Library Version 126.96.36.199
Getting Started with JE
2. Less total writing takes place. If a single record is modified more than once, or modified
and deleted, then only the final result must be written. If a record is inserted and
deleted before a database sync or close occurs, nothing at all is written to disk. The same
advantage holds for writing internal index information.
Deferred write databases are useful for applications that perform a great deal of database
modifications, record additions, deletions, and so forth. By delaying the data write, you delay
the disk I/O. Depending on your workload, this can improve your data throughput by quite a
While the durability of a deferred write database is only guaranteed when Database.sync()
is called or the database is properly closed, writing may also occur at other times. For
example, a JE checkpoint will effectively perform a Database.sync() on all deferred write
databases that are open at the time of the checkpoint. If you are using deferred write to load
a large data set, and you want to reduce writing as much as possible during the load, consider
disabling the JE checkpointer.
Also, if the JE cache overflows as database modifications occur, information discarded from
the cache is written to disk in order to avoid losing the changes. If you wish to reduce this
writing to a minimum, configure your cache to be large enough to hold the entire data set
being modified, or as large as possible.
Despite the examples noted in the previous paragraphs, there is no guarantee that
changes to a deferred write database are durable unless Database.sync() is called
or the database is closed. If you need guaranteed durability for an operation, consider
using transactions instead of deferred write.
You should also be aware that Database.sync() is a relatively expensive operation because
all outstanding changes to the database are written, including internal index information. If
you find that you are calling Database.sync() frequently, consider using transactions.
All other rules of behavior pertain to deferred write databases as they do to normal
databases. Deferred write databases must be named and created just as you would a normal
database. If you want to delete the deferred write database, you must remove it just as you
would a normal database. This is true even if the deferred write database is empty because its
name persists in the environment's namespace until such a time as the database is removed.
Note that determining whether a database is deferred write is a configuration option. It is
therefore possible to switch a database between "normal" mode and deferred write database.
You might want to do this if, for example, you want to load a lot of data to the database.
In this case, loading data to the database while it is in deferred write state is faster than in
"normal" state, because you can avoid a lot of the normal disk I/O overhead during the load
process. Once the load is complete, sync the database, close it, and and then reopen it as a
normal database. You can then continue operations as if the database had been created as a
To configure a database as deferred write, set DatabaseConfig.setDeferredWrite() to
true and then open the database with that DatabaseConfig option.