Data Management

Where is the data of my database located?

EclipseStore connects your application’s entity graph residing in memory to a physical form of data (i.e. persistent data) to/from which entity data is stored/loaded as required. By default, data is stored on the local file system in the directory configured via setStorageDirectory() or the storage-directory configuration property. See Storage Files and Directories for details on the directory structure and file layout.

What if my database is really big?

EclipseStore uses the common concept of Lazy Loading, allowing you to define which parts of your data (entity sub-graphs) are loaded only when required instead of eagerly at startup. A few well-placed lazy references in your entity model make your application load only a tiny bit of "head" entities at startup time and load everything else later on demand. This allows the handling of arbitrarily big databases with relatively small memory requirements.

How does storage size grow over time?

When objects are updated or deleted, the old data is not immediately removed from the storage files. Instead, new data is appended and the deleted data becomes "garbage." The housekeeping process runs in the background to reclaim space from deleted or updated objects.

You can monitor storage growth through the monitoring JMX beans, which report the amount of persisted data.

How can I reduce storage size?

  • Ensure housekeeping is configured with sufficient time budget to keep up with updates

  • Store only the data you need — avoid storing derived or cached data

  • Use Lazy references to manage what is kept in memory

How do I handle concurrent access?

EclipseStore is designed for single-process access. The storage manager itself handles the internal persistence operations (reading and writing storage files) in a thread-safe manner.

However, your application code is responsible for synchronizing access to the shared object graph. Since EclipseStore stores plain Java objects that live in memory, the same concurrency rules apply as for any shared mutable data in Java. Without proper synchronization, concurrent reads and writes to the same objects can cause race conditions and inconsistent state — just like with any in-memory data structure.

Use locking or other synchronization strategies to protect your data during concurrent access.

  • Do not open the same storage from multiple processes simultaneously — this will lead to data corruption.

  • The lock file mechanism helps prevent accidental concurrent access.

  • For multi-process or distributed access, consider using EclipseStore behind a service API layer.

Can I recover from data corruption?

If storage files become corrupted (e.g., due to disk failure or a crash during write):

  1. Check if a continuous backup or full backup is available and restore from it

  2. If no backup is available, try starting the storage with the StorageEntityCollector.Creator.Unchecked() option (see Troubleshooting)

  3. Contact the EclipseStore community for assistance with complex recovery scenarios

Can I export my data?

Yes. EclipseStore provides binary Import / Export to transfer storage data between instances. The exported binary data can also be converted to and from CSV for inspection or editing with external tools. See Import / Export for details.