If i call explicitly to set_flags on the environment with TXN_NOSYNC, and create the transaction tn_begin() with TXN_SYNC, which one will be taken into account in this case when committing the transaction? Will it be flushed to log synchronously(like the transaction) or asynchronoulsy(like the environment)?The setting on the transaction is the one that is used and it overrides the setting on the environment.
Also I am using BDB 5.1.19, and i actually use the replication manager. Do i understand correctly that the difference between TXN_SYNC and TXN_NOSYNC as following?Basically you are correct with a few additional points.
TXN_SYNC: this means that when the thread calls the function commit() on a given transaction, the call will be blocked(and hence the thread) until the data of the transaction is written to disk and sent to the replica and ack is received. Is this understanding accurate?
TXN_NOSYNC: this means that when the thread calls the function commit() on a given transaction, the writin to disk + sending and receiving ack on the transaction will be done asynchronously which i believe is using another thread to get the async behavior. Is that understanding correct?No, this is not correct. Notice that our terminology is SYNC/ NOSYNC rather than SYNC /ASYNC.
You say:No, the write of the changes to the log file and the log flush will happen at the earlier of the following two events: 1. your next checkpoint or 2. when the in-memory log buffer fills up and needs more space.
"For TXN_NOSYNC, the commit of a transaction will not write its changes to the log and will not flush the log. Writing the changes to the log and flushing the log are the "SYNC" that we avoid doing if TXN_NOSYNC is set."
I am confused about the TXN_NOSYNC, are you saying that when using TXN_NOSYNC, all the db-put of this transactions will not be written to the disk at all?
If this is true does that mean if the slave is not there for 1 hour, and the master box reboots, does that mean that the all the transactions of the last hour will be lost?If you haven't done a checkpoint or if the in-memory log buffer hasn't happened to fill up in the last hour, then yes, those transactions are lost.
This makes me re-think my understanding of how BDB works.No, db_put does not cause the log to be written to disk.
Is the following correct?
A typical application like the one we develop is basically writing to database(db_put() for ex) and then committing transactions.
My understanding is:
- Every db->put will never write to disk but to the shared mem buffer of BDB. Is it correct or db->put could trigger write to disk too?
- At commit time, all of the changes in the transaction will be put to log file as well as sent to the slave. Is it correct?If you do not use TXN_NOSYNC, the changes are written to the log file at commit time.
Are you saying that at commit time with the transaction is TX_NOSYNC it will be just sent to the slave but not written to disk? Or is the NOSYNC saying just that the data is not written to the log immediately when performing the commit() call but later using some kind of thread?Regardless of TXN_NOSYNC, changes are sent to the slave as they occur.