I'm referring to the scenario of applying 2PC to heterogenous distributed transactions. Say I want to write to both database A and database B together in atomic fashion. Now reads and writes to database A and B each themselves could be from multiple concurrent users. Normally in a high throughput environment we'd prefer A and B to use Optimistic Locking (row versioning for example) instead of Pessimistic Locking so high volume concurrent read only operations will not be blocked.
But if A and B are also involved as a whole in a 2PC protocol, does that mean they HAVE to use Lock during each of their PREPARE phases for those relevant data changes? And basically need to hold that lock until COMMIT are done? Because the transaction on each is forced split into two parts, and you simply can't just do "prepare to write a value that I read now is the most up-to-date value" cos when you actually commit it later, it could very well be changed, if the resource isn't locked?
Does that mean for example, in distributed transaction environments involving multiple databases, each of their own concurrent throughput will be limited simply because they need to be coordinated with other databases even though they on their own could have used Optimistic Locking?
