Hi Francisco,
Still, I have a doubt as per your example both are trying to update the same tuple so it may produce two different copies right?
I read some blocks they mentioned drawback above two things
It may lead to lost update also
For example, two transactions are going to increase the amount on the same account by $100 . The first transaction reads the current value ($1000) and then the second transaction reads the same value. The first transaction increases the amount (this gives $1100) and writes this value. The second transaction acts the same way: it gets the same $1100 and writes this value. As a result, the customer lost $100.
Will u please provide more details
Serialize is the solution to this issue.
Rama:
On Mon, Jul 13, 2020 at 9:52 AM Rama Krishnan <raghuldrag@gmail.com> wrote:
> I m preparing for interview one of the recruiter asked me mvcc drawbacks as i told due to mvcc it use more space and need to perform maintenance activity.
> Another one is the same data causes an update conflict because two different transactions can update the same version of the row.
> he told its wrong, kindly tell me will you please tell me its correct or wrong?
I'm not sure I understand your question too well, you may want to
refresh/expand.
One interpretation is, on a pure MVCC contest, two transactions, say 5
and 6, could try to update a tuple valid for [1,) and end up
generating two new tuples, [5,), [6,) and closing the original at
either [1,5) or [1,6) .
That's why MVCC is just a piece, locking is other. On a MVCC the
tuples are locked while a transaction manipulates them. Other
transactions may read them, which is why readers do not block writers,
but two updates on the same tuple serialize.
Francisco Olarte.