Why would you want to use both optimistic and pessimistic schemes together?
Any intuition behind why you would use an optimistic scheme for reads and a pessimistic scheme for writes.
colorblue
@msfernan The idea of using both is that each has its use case and if you can correctly profile your system you can do different schemes depending on the properties of certain transactions. For instance there are many more reads in a system then writes and since the probability is much lower for a read to be conflicting we want to assume success therefore we use a optimistic scheme. Meanwhile for the writes if we add more explicit locking with pessimistic schemes we can assure we don't abort as often.
yangwu
also, pessimistic schemes costs more, there is no need to use such schemes to deal with read-read operations where no conflicts would happen at all
nmrrs
A nice thing about optimistic transactions seems to be that they guarantee that we'll make progress on at least one transaction. Transactions only get aborted when another transaction is committing, which means that the committing transaction is guaranteed to complete.
Why would you want to use both optimistic and pessimistic schemes together?
Any intuition behind why you would use an optimistic scheme for reads and a pessimistic scheme for writes.
@msfernan The idea of using both is that each has its use case and if you can correctly profile your system you can do different schemes depending on the properties of certain transactions. For instance there are many more reads in a system then writes and since the probability is much lower for a read to be conflicting we want to assume success therefore we use a optimistic scheme. Meanwhile for the writes if we add more explicit locking with pessimistic schemes we can assure we don't abort as often.
also, pessimistic schemes costs more, there is no need to use such schemes to deal with read-read operations where no conflicts would happen at all
A nice thing about optimistic transactions seems to be that they guarantee that we'll make progress on at least one transaction. Transactions only get aborted when another transaction is committing, which means that the committing transaction is guaranteed to complete.