You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@hudi.apache.org by GitBox <gi...@apache.org> on 2021/10/23 21:41:39 UTC

[GitHub] [hudi] manojpec edited a comment on pull request #3827: [HUDI-2573] Fixing double locking with multi-writers

manojpec edited a comment 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 dont 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: commits-unsubscribe@hudi.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org