Using store.sync in threaded environment

Question

Dear All,
I just wanted to know what will happen during this condition.
I have been using berkeley DB java edition for a while.
I have this environment set
private Environment myEnv;
private EntityStore store;
private PrimaryIndex pk;
private SecondaryIndex sk;
EnvironmentConfig myEnvConfig = new EnvironmentConfig();
myEnvConfig.setAllowCreate(true);
myEnvConfig.setSharedCache(true);
myEnv = new Environment(envHome, myEnvConfig);
StoreConfig storeConfig = new StoreConfig();
storeConfig.setAllowCreate(true);
storeConfig.setDeferredWrite(true);
store = new EntityStore(myEnv, storeName, storeConfig);
As you can see I have set deferredwrite as true .
Due to this I have to use sync.store whenever inserts and delete take place.
I have threaded environment . I just wanted to know .
Due to the above setting during inserts and delete happening in together will my berkeley db cache ever get corrupted .
I have not yet seen any issue .
Is there by any chance cache would be corrupted. Please update me on this
Regards
Ashwin

Answer 1

Ashwin,
When you use deferred write, you are (a) running without transactions, and (b) reducing your durability guarantee. That is, if the environment goes down, you might lose some portion of the operations you were doing with deferred write.
(b) only applies when the environment crashes and restarts. I think that you are asking about concurrent reads to the deferred write database while the environment is up. In that case, the issues you have to think about are the same as with regular non-transactional updates. Because you are not using transactions, there is a chance that a reading thread will see data that is logically inconsistent. For example, since you have secondary indices, an insert into the store will result in an insert both into the primary and the secondary index. Since the insert is non transactional, those two updates are not atomic, and another thread may happen to read the primary before the secondary index insert has completed.
However, you should never see a data record that is physically corrupt. Each data record will be correct, which considered on its own.
Regards,
Linda