Sumit6307 commented on PR #8007: URL: https://github.com/apache/incubator-seata/pull/8007#issuecomment-4007412916
> Regarding your first point: if the database-level local lock is not exclusive, the generated undo log will be incorrect. The global lock and the local lock (i.e., the database’s exclusive lock) must cooperate to ensure undo logs are correct in AT mode; they form a reciprocal relationship. The local lock prevents other transactions from interfering with the current branch transaction so that a correct undo log can be created. After producing the undo log, the branch registers with the server and then acquires the corresponding global lock. Only when the global lock is obtained—which indicates no other distributed transactions hold the resources associated with that branch lock—can the local transaction be committed. This prevents dirty writes and allows the local lock to be released safely. Only by holding both the local lock and the global lock can correctness be guaranteed in a distributed scenario and the corresponding local lock be safely released. If you obtain only th e global lock without the local lock, that does not mean the undo log was created correctly; this will lead to incorrect data during two-phase rollback. @funky-eyes Thank you for the detailed technical feedback. You are absolutely correct regarding the reciprocal relationship between Local and Global locks. In a traditional OLTP database, the Local Lock is essential to ensure the before image remains consistent until the Global Lock is secured. Since ClickHouse and the MergeTree family handle concurrency using MVCC and do not support pessimistic row level locking, I acknowledge that a pure AT implementation is theoretically limited when concurrent non Seata writers are present. However, a robust best effort AT mode can still be achieved for ClickHouse by leveraging its recent capabilities. Snapshot isolation and conflict detection can be used through experimental transactions by enabling allow experimental transactions equals 1. This provides snapshot isolation where, if another transaction modifies the data after the before image is read but before the local commit occurs, ClickHouse MVCC will detect the conflict and the transaction will fail. This effectively shifts the approach from pessimistic locking used in systems like MySQL to optimistic concurrency control, which aligns better with OLAP database behavior. Synchronous execution is also prioritized by using mutations sync equals 1 so that even without a lock the state is persisted and verifiable before proceeding to phase two. This pull request mainly focuses on foundational SPI work by introducing SQL generation logic and TableMeta handling for ClickHouse. Even if a stricter implementation is introduced in the future, this infrastructure is required as the first step to properly support ClickHouse within Seata. I am open to adding a warning or experimental label to the ClickHouse resource manager and documenting that it relies on optimistic concurrency through snapshot isolation. I would appreciate your thoughts on whether this pragmatic approach aligns with the direction of supporting OLAP style databases within Seata. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
