Lock Manager Nested LUW Event Propagation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing locking mechanisms in object-oriented systems fail to manage locks consistently in systems performing nested logical units of work (LUWs) in transient memory, leading to locks being inadvertently left on objects after they are released, which can prevent later access to the object.
Innovation Solution
A method and system for managing locks on objects dependent on nested LUWs, where a lock manager registers with an LUW manager to receive events related to the inner LUW, determining whether to retain or release the lock based on the LUW's state, ensuring the lock status is consistent with the nested LUW's state.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a lock manager places a lock on an object affected by LUW operations, then data consistency is ensured, but the lock may be inadvertently left on the object after the LUW is committed, preventing access to the object
Solution Approach 1:
The lock manager registers with the LUW manager to receive notifications about LUW events (commit, rollback, failure). Based on these feedback events, the lock manager automatically propagates lock status changes to affected objects. When the LUW commits successfully, the lock is released; when the LUW rolls back or fails, the lock is maintained or released appropriately, ensuring data consistency while enabling proper object access.
Solution Approach 2:
The lock manager acts as an intermediary between the LUW manager and objects. It receives lock requests for objects affected by LUW operations, maintains lock status based on LUW events, and automatically propagates lock changes to the appropriate objects. This intermediary mechanism ensures that locks are properly managed without requiring direct intervention from applications, resolving the contradiction between maintaining consistency and enabling access.
2Ease of operation
If the lock manager releases the lock after the LUW is committed, then object access is enabled, but data consistency may be compromised if the lock is released prematurely
Solution Approach 1:
The lock manager receives feedback events from the LUW manager indicating whether the LUW committed successfully, rolled back, or failed. The lock status is propagated only after receiving confirmation of successful commit, ensuring data consistency is maintained while enabling object access at the appropriate time. The lock is held during the LUW execution and only released upon successful completion.
3Reliability
If the lock manager maintains the lock until the LUW is committed, then data consistency is ensured, but object access is blocked during the LUW execution
Solution Approach 1:
The locking mechanism is segmented to apply locks only to specific objects affected by LUW operations rather than all objects in the system. The lock manager identifies and locks only the subset of objects that will be modified by the LUW, allowing other objects to remain accessible. This segmentation reduces the time objects are locked while maintaining data consistency for the affected objects.
4Device complexity
If the lock manager does not register with the LUW manager, then system complexity is reduced, but lock status becomes inconsistent with LUW state
Solution Approach 1:
The lock manager registers with the LUW manager to receive automated notifications about LUW events. This feedback mechanism ensures lock status remains consistent with the LUW state without requiring complex manual tracking or synchronization logic. The registration process is simple, and the automated event-driven approach reduces overall system complexity while maintaining reliability.
Data Source
AI summary
Systems and methods are disclosed for managing a lock on an object dependent upon a nested LUW. The disclosed systems and methods may include registering a lock manager with an LUW manager responsible for managing a nested LUW on a buffer. The nested LUW may comprise an inner LUW and an outer LUW. The systems and method may further include locking an object affected by the inner LUW of the nested LUW. The LUW manager may transmit to the lock manager any events pertaining to the inner LUW. The lock manager may be operative to determine, based on the events pertaining to the LUW received from the LUW manager, whether the lock should be retained or released such that the status of the lock is consistent with the state of the nested LUW.