Prasad, Since optimistic transactions do not acquire key locks until prepare phase, it is possible that the key value is concurrently changed before the prepare commences. Optimistic exceptions is thrown exactly in this case and suggest a user that they should retry the transaction.
Consider the following example: Thread 1: Start tx 1, Read (key1) -> val1 Thread 2: Start tx 2, Read (key2) -> val1 Thread 1: Write (key1, val2) Thread 1: Commit Thread 2: Write (key1, val3) Thread 2: Commit *Optimistic exception is thrown here since current value of key1 is not val1 anymore* When optimistic transactions are used, a user is expected to have a retry logic. Alternatively, a pessimistic repeatable_read transaction can be used (one should remember that in pessimistic mode locks are acquired on first key access and released only on transaction commit). Hope this helps, --AG
