Isolation level configuration

Question

Hello there,
I am converting our not-transaction based application to use transactions. As I want to reduce the performance impact I am configuring some transactions to some lesser isolation levels. As far as I understand from the docs, the general way to do it is to set proper isolation level in TransactionConfig when creating a transaction.
But from what I see in the docs, it's possible to use PrimaryIndex.get() third parameter (lockMode) to specify isolation for the specific operation as well.
So my question is: what are props and cons of per-operation isolation configuration compared to per-transaction isolation configuration?
I.e. I'm considering which approach is better:
1.
TransactionConfig txnConfig = new TransactionConfig();
txnConfig.setReadUncommitted(true);
Transaction txn = myEnv.beginTransaction(null, txnConfig);
for (id : idList)
primaryIndex.get(txn, id, null);
2.
Transaction txn = myEnv.beginTransaction(null, null);
for (id : idList)
primaryIndex.get(txn, id, LockMode.READ_UNCOMMITTED);
In general I understand that specifying isolation on per-operation basis probably was intended to be used as a tool for locally changing the general transaction setting like
3.
TransactionConfig txnConfig = new TransactionConfig();
txnConfig.setReadUncommitted(true);
Transaction txn = myEnv.beginTransaction(null, txnConfig);
for (id : idList)
primaryIndex.get(txn, id, id == 5? LockMode.READ_COMMITTED : null);
but I want to know if the 2nd approach is legal and would not lead to some bad consequences.

Answer 1

Hello Linda,
Thanks for clarification!
Still your last note makes me think that I'm doing something that I should not. When you say :
it does seem unusual to have a transaction where you always choose to use READ_UNCOMMITTEDdo you mean that I don't have to use a transaction for a read-only operations sequence?
Here's my use-case. In my application I have 2 types of threads:
Threads of the 1st type would just update some record in the DB. I do it like this:
Transaction txn = myEnv.beginTransaction(null, null);
Record record = primaryIndex.get(txn, id, LockMode.RMW);
record.update(...);
primaryIndex.putNoReturn(txn, record);
txn.commit();
I'm using LockMode.RMW to prevent other threads from writing this record without reading it first.
Threads of the 2nd type would perform reading of some set of records. I do it like this:
Transaction txn = myEnv.beginTransaction(null, null);
int result = 0;
for (id : idList)
Record record = primaryIndex.get(txn, id, LockMode.READ_UNCOMMITTED);
result += record.getValue();
txn.commit();
or
Transaction txn = myEnv.beginTransaction(null, null);
int result = 0;
EntityCursor<Record> cursor = primaryIndex.entities(txn, CursorConfig.READ_UNCOMMITTED);
for (Record record : cursor)
result += record.getValue();
cursor.close()
txn.commit();
I am using READ_UNCOMMITTED there to reduce chances of locking, as I'm not really interested whether I get the value before it gets updated by some 1st type transaction or after.
Can you give me any advice on how I should do it in more correct way?
Should I just remove the transaction from the 2nd type of threads (so there would be no questions on what does the txn.commit() commits there)?
Does the fact that I'm using LockMode.READ_UNCOMMITTED means that I can get the record in some internally-inconsistent state?