Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/himansaBro/JungleConfig/llms.txt

Use this file to discover all available pages before exploring further.

By default, JungleConfig operates in auto-commit mode — every call to Set, Remove, or RemoveAllKeys is immediately serialized and flushed to the backing store. Transactions let you batch multiple operations together in memory and then either commit them all at once or discard them entirely, giving you full control over when data becomes durable.

​
Auto-commit mode (default)

In auto-commit mode you simply call Set and the value is persisted before the next line of code runs. This is the simplest way to use JungleConfig and requires no extra setup. 
JungleConfig config = new JungleConfig(new File("app.conf"));

config.Set("app.name", "MyService");
config.Set("app.version", "1.0.0");

String name = config.get("app.name", String.class); // "MyService"

​
Manual transactions

Calling BeginTransaction() switches the instance into manual mode — auto-commit is disabled and all subsequent Set, Remove, and RemoveAllKeys calls are queued in memory rather than written through immediately.
MethodReturn typeWhat it does
BeginTransaction()JungleConfigDisables auto-commit; starts buffering operations
Commit()JungleConfigFlushes the current buffer to the backing store; transaction stays open
Rollback()JungleConfigDiscards the buffer; nothing is written
EndTransaction()voidRe-enables auto-commit and immediately flushes any remaining pending saves
All four methods are chainable except EndTransaction(), which returns void. 
JungleConfig config = JungleConfig.InMemoryConfig();

config.BeginTransaction();
config.Set("user.name", "Alice");
config.Set("user.role", "admin");
config.Set("user.active", true);
config.Commit(); // writes all three atomically

String name = config.get("user.name", String.class); // "Alice"

​
Rollback example

If something goes wrong before you commit, call Rollback() to throw away every queued operation. Only the in-memory buffer (saveQuery and remList) is cleared — nothing is written to or removed from the backing store. Any writes that were already flushed by an earlier Commit() call within the same transaction are not reversed; Rollback() can only discard what has not yet been committed. 
config.BeginTransaction();
config.Set("feature.flag", "enabled");
config.Rollback(); // discard — feature.flag is never written

boolean exists = config.Exists("feature.flag"); // false

​
BeginTransaction vs EndTransaction

EndTransaction() does two things at once: it re-enables auto-commit and immediately flushes any saves that are still pending in the buffer. Internally, it sets AutoCommit = true and then calls send(), which calls flush() because AutoCommit is now true. Use it when you want to close out the transaction and return to normal auto-commit behaviour in one step. Commit(), by contrast, only flushes the current buffer — the transaction remains open and auto-commit stays off (AutoCommit remains false). You can call Commit() multiple times within a single transaction to checkpoint intermediate batches without ending the transaction: 
config.BeginTransaction();

// First batch
config.Set("batch.a", "1");
config.Set("batch.b", "2");
config.Commit(); // flush batch 1 — transaction still active, AutoCommit still false

// Second batch
config.Set("batch.c", "3");
config.Commit(); // flush batch 2 — transaction still active

config.EndTransaction(); // re-enable auto-commit and flush anything left
Pending transaction state is held in NativeInternalTransaction.saveQuery (entries to write) and remList (keys to delete). Calling Rollback() clears both lists in-place without touching the underlying file or cache, so the on-disk state remains unchanged. Importantly, Rollback() only undoes writes that have not yet been committed — any batches already flushed by a previous Commit() call within the same transaction are permanent and cannot be rolled back.
Transactions are not thread-safe. If multiple threads share a single JungleConfig instance, you must use external synchronization (for example, synchronized blocks or a ReentrantLock) to serialize access around BeginTransaction/Commit/Rollback call sequences.

Build docs developers (and LLMs) love

Get started for freeTalk to us