manojpec commented on pull request #3827: URL: https://github.com/apache/hudi/pull/3827#issuecomment-950218626
Overall Approach/Design Comment: Exposing locking semantics to callers is a bit dangerous. Caller usually doet know the internals of abstract class interfaces and cannot decide when to use what lock/unlock versions. The core problem here is lock reentrancy. Few higher level actions have sub actions and taking the same exclusive lock across actions can lead to deadlock. Instead of viewing this as implementation specific (lock) issues, can we see this as transaction manager issue? That is a higher level transaction started doesn't want to start sub transactions, right? If thats the case, can we instantiate the Rollback/Clean sub actions with no-op transaction manager? Because the transaction manager in these actions have the only task of locking/unlocking and so the presence of Transaction manager can inform indirectly inform them to relax transaction and there by the locking. Please let me know if I got the core problem wrong? -- 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]
