System and method for implementing a lock management system in a distributed network environment

Abstract

The present disclosure provides a system (108) and a method (500) for implementing a lock management system in a distributed network environment. The system (108) initiates a request to create a lock on the resource. The system (108) verifies whether the lock already exists on the requested resource. Upon verifying an absence of the lock for the requested resource, the system (108) acquires the lock for the resource. The system (108) updates the lock details in an external cache (112), if the acquiring of the lock for the requested resource is successful. The system (108) releases the lock for the requested resource if the acquiring of the lock for the requested resource is unsuccessful for a predefined number of times.

Description

SYSTEM AND METHOD FOR IMPLEMENTING A LOCK MANAGEMENT SYSTEM IN A DISTRIBUTED NETWORK ENVIRONMENTRESERVATION OF RIGHTS

[0001] A portion of the disclosure of this patent document contains material, which is subject to intellectual property rights such as, but are not limited to, copyright, design, trademark, Integrated Circuit (IC) layout design, and / or trade dress protection, belonging to Jio Platforms Limited (JPL) or its affiliates (hereinafter referred as owner). The owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights whatsoever. All rights to such intellectual property are fully reserved by the owner.TECHNICAL FIELD

[0002] The present disclosure relates generally to the field of distributed computing. In particular, the present disclosure relates to a system and a method for implementing a lock management system in a distributed network environment.DEFINITIONS

[0003] As used in the present disclosure, the following terms are generally intended to have the meaning as set forth below, except to the extent that the context in which they are used indicates otherwise.

[0004] The expression “distributed network environment” used hereinafter in the specification refers to a computing environment where multiple interconnected computers or nodes work together to perform computational tasks and manage resources. The tasks and data are distributed among various nodes, which can be computers, servers, other devices, connected through a network.

[0005] The expression “network node” used hereinafter in the specification refers to a computing entity or component within the distributed network environmentthat is capable of hosting one or more application instances. The network node may include, but is not limited to, a server, a computer, a user equipment (UE), or a microservice.

[0006] The expression “application instance” used hereinafter in the specification refers to a specific deployment or execution of an application across the distributed network environment. The application instances are spread across the different nodes (computers or servers) within the distributed computing environment and may perform specific functions or a set of operations required by the application. Each application instance may interact with shared resources and participate in lock acquisition or release operations.

[0007] The expression “resource” used hereinafter in the specification refers to a logical, virtual, or physical component that is shared and managed across processes or application instances in the distributed environment. The resources may include, but are not limited to, database records, files, service configurations, session objects, memory buffers, or computational units, which are subject to locking to ensure synchronized access.

[0008] The expression “key” used hereinafter in the specification refers to an identifier or value used to uniquely identify and access resources across the distributed network environment. The key may be used to reference a specific lock or resource instance in an external cache.

[0009] The expression “external cache” used hereinafter in the specification refers to a high-speed storage and processing service / memory located in the distributed network environment. The external cache is a network-accessible caching layer that enhances performance by storing and quickly providing access to frequently used data to improve efficiency and responsiveness in the distributed network environment.

[0010] The expression “lock” used hereinafter in the specification refers to a mechanism that prevents a state of a resource from being modified or accessed by multiple threads of execution at once. The lock is used to synchronize different processing threads, with set limits to avoid unlimited accessibility of a certain resource within a computing environment (e.g., the distributed network environment).

[0011] These definitions are in addition to those expressed in the art.BACKGROUND

[0012] The following description of related art is intended to provide background information pertaining to the field of the disclosure. This section may include certain aspects of the art that may be related to various features of the present disclosure. However, it should be appreciated that this section be used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of prior art.

[0013] In a distributed system, a collection of nodes (e.g., computers, servers, or virtual instances) work together to execute computational tasks and manage shared resources. These nodes collectively appear as a unified system but operate independently, often across geographically or logically separated environments. In such distributed systems, multiple application instances or services may simultaneously attempt to access or modify the same resources. This concurrent access may result in race conditions, data inconsistencies, and resource contention. Additionally, coordination across multiple nodes is inherently complex, and node failures may leave resources in an inconsistent or partially updated state, adversely impacting the overall stability and scalability of the distributed system.

[0014] Further, the distributed system needs to support concurrent access to resources, e.g., files, directories, and applications, while also maintaining a consistentstate. When different nodes may access the resources concurrently (e.g., in response to read and write requests sent by users), it is important that the resource remains consistent. The updates to the resources performed by one node should be visible to other nodes of the distributed system. Also, consistency requires tolerance for node failures, such that if a node fails while performing an update to the resource, the incomplete resource operation transactions need to be either completed or aborted.

[0015] In addition, the conventional distributed system often relies on a traditional locking mechanism, such as a mutexes, a semaphore, which can create performance bottlenecks and single points of failure. The usage of conventional locking mechanisms in the distributed system causes deadlocks, priority inversion, overhead and starvation situations. In scenarios where a node that has acquired a lock crashes, the associated resource may remain indefinitely locked, requiring manual intervention to detect and resolve the issue. Such failure scenarios reduce system availability and increase the risk of data inconsistency or downtime.

[0016] Hence, there is a need to provide a method and a system that can address the shortcomings of existing solutions.OBJECTIVES OF THE DISCLOSURE

[0017] Some of the objectives of the present disclosure, which at least one embodiment herein satisfies, are as follows:

[0018] An objective of the present disclosure is to provide a system and a method for implementing a lock management system in a distributed network environment.

[0019] Another objective of the present disclosure is to provide a system and a method for performing a distributed locking mechanism using an external cache to enhance data consistency and reduce latency.

[0020] Another objective of the present disclosure is to provide a system and a method that ensures that only one process may modify a resource at a time, preventing conflicting changes and maintaining data integrity.

[0021] Another objective of the present disclosure is to provide a system and a method for managing and controlling access to shared resources to enable task coordination.

[0022] Another objective of the present disclosure is to provide a system and a method for acquiring and releasing locks via an application programming interface (API).

[0023] Yet another objective of the present disclosure is to provide a system and a method for configuring custom locking policies and retry mechanisms to allow flexibility in a distributed computing environment (e.g., the distributed network environment).

[0024] Other objectives and advantages of the present disclosure will be more apparent from the following description, which is not intended to limit the scope of the present disclosure.SUMMARY

[0025] In an exemplary embodiment, a method for implementing a lock management system in a distributed network environment is described. The method includes receiving a request from a network node associated with the distributed network environment to create a lock for a resource on which at least one operation is to be performed. The method further includes determining whether the lock for the requested resource already exists in a memory of the distributed network environment. Upon determining that the lock does not exist, the method further includes creating a new lock for the requested resource. The method includes storing details of the newlock in the memory. The method includes acquiring the new lock for a predefined time period. The method further includes periodically updating a status of the acquired new lock in the memory.

[0026] In an embodiment, the at least one operation includes one of a create operation, a modify operation, and a delete operation on the requested resource.

[0027] In an embodiment, upon performing the at least one operation on the requested resource, the method includes receiving an unlock request corresponding to the acquired new lock from at least one application platform. The method further includes releasing the acquired new lock from the requested resource in response to receiving the unlock request.

[0028] In an embodiment, the method further includes detecting a failure to create the new lock in the memory. Upon detecting the failure, the method further includes retrying the creation of the new lock for a predefined number of attempts. Upon unsuccessful creation of the new lock after the predefined number of attempts, the method further includes releasing the lock for the requested resource that already exists in the memory.

[0029] In an embodiment, the details of the created lock include a unique identifier (ID) associated with the requested resource and an expiration time for the created new lock.

[0030] In an embodiment, the resource include at least one of: a record, a file, a configuration, or a data entity.

[0031] In an embodiment, the memory is a cache memory located in the distributed network environment.

[0032] In an embodiment, the status includes one of an available status of the acquired new lock and an unavailable status of the acquired new lock.

[0033] In an embodiment, upon receiving the request, maintaining a counter for each request received for creating the new lock, each unlock request for releasing the new lock, each successful acquisition of the new lock for the requested resource, successful lock updates in the memory, successful lock release and successful record deletion from the memory

[0034] In another exemplary embodiment, a system for implementing a lock management system in a distributed network environment is disclosed. The system includes a receiving module configured to receive a request from a network node associated with the distributed network environment to create a lock for a resource on which at least one operation is to be performed. The system further includes a determining module configured to determine whether the lock for the requested resource already exists in a memory of the distributed network environment. The system further includes a creating module configured to create a new lock for the requested resource, upon determining that the lock does not exist. The creating module is further configured to store details of the new lock in the memory. The system further includes an acquiring module configured to acquire the new lock for a predefined time period. The system further includes an updating module configured to periodically update a status of the acquired new lock in the memory.

[0035] In yet another exemplary embodiment, the present disclosure discloses a computer program product comprising a non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform a method for implementing a locking management system in a distributed network environment. The method includes receiving a request from a network node associated with the distributed network environment to create a lock for a resource on which at least one operation is to be performed. The methodfurther includes determining whether the lock for the requested resource already exists in a memory of the distributed network environment. Upon determining that the lock does not exist, the method further includes creating a new lock for the requested resource. The method includes storing details of the new lock in the memory. The method includes acquiring the new lock for a predefined time period. The method further includes periodically updating a status of the acquired new lock in the memory.BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWING

[0036] The accompanying drawings, which are incorporated herein, and constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods and systems in which like reference numerals, refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale; emphasis is instead being placed upon clearly illustrating the principles of the present disclosure. Some drawings may indicate the components using block diagrams and may not represent the internal circuitry of each component. It will be appreciated by those skilled in the art that disclosure of such drawings includes disclosure of electrical components, electronic components, or circuitry commonly used to implement such components.

[0037] FIG. 1 illustrates an exemplary network architecture of a system for implementing a locking management system in a distributed network environment, in accordance with an embodiment of the present disclosure.

[0038] FIG. 2 illustrates an exemplary block diagram of the system, in accordance with an embodiment of the present disclosure.

[0039] FIG. 3 illustrates an exemplary system architecture, in accordance with an embodiment of the present disclosure.

[0040] FIG. 4 illustrates an exemplary flow diagram of a method for implementing the locking management system in a distributed network environment, in accordance with an embodiment of the present disclosure.

[0041] FIG. 5 illustrates another exemplary flow diagram of a method for implementing the locking management system in the distributed network environment, in accordance with an embodiment of the present disclosure.

[0042] FIG. 6 illustrates an example computer system in which or with which the embodiments of the present disclosure may be implemented.

[0043] The foregoing shall be more apparent from the following more detailed description of the disclosure.LIST OF REFERENCE NUMERALS100 - Network Architecture102-1, 102-2... 102-N - Plurality of Users104-1, 104-2... 104-N - Plurality of User Equipments106 - Network108 - System110 - Server112 - External Cache200 - Block Diagram202 - Processor(s)204 - Memory206 - Interface(s)208 - Processing Engine210 - Receiving module 212 - Determining Module214 - Creating Module216 - Acquiring Module218 - Releasing Module220 - Updating Module 222 - Database300 - Exemplary System Architecture302 - Application Instances400, 500 - Flow Diagram600 - Computer System 610 - External Storage Device620 - Bus630 - Main Memory640 - Read Only Memory650 - Mass Storage Device660 - Communication Port670 - ProcessorDETAILED DESCRIPTION

[0044] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features. An individual feature may not address any of the problems discussed above or might address only some of the problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein. Example embodiments of the present disclosure are described below, as illustrated in various drawings in which like reference numerals refer to the same parts throughout the different drawings.

[0045] The ensuing description provides exemplary embodiments only and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the disclosure as set forth.

[0046] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not to obscure theembodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.

[0047] Also, it is noted that individual embodiments may be described as a process that is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.

[0048] The word “exemplary” and / or “demonstrative” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and / or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive like the term “comprising” as an open transition word without precluding any additional or other elements.

[0049] Reference throughout this specification to “one embodiment” or “an embodiment” or “an instance” or “one instance” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout thisspecification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0050] The terminology used herein is to describe particular embodiments only and is not intended to be limiting the disclosure. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context indicates otherwise. It will be further understood that the terms “comprises” and / or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. As used herein, the term “and / or” includes any combinations of one or more of the associated listed items. It should be noted that the terms “mobile device”, “user equipment”, “user device”, “communication device”, “device” and similar terms are used interchangeably for the purpose of describing the invention. These terms are not intended to limit the scope of the invention or imply any specific functionality or limitations on the described embodiments. The use of these terms is solely for convenience and clarity of description. The invention is not limited to any particular type of device or equipment, and it should be understood that other equivalent terms or variations thereof may be used interchangeably without departing from the scope of the invention as defined herein.

[0051] As used herein, an “electronic device”, or “portable electronic device”, or “user device” or “communication device” or “user equipment” or “device” refers to any electrical, electronic, electromechanical and computing device. The user device is capable of receiving and / or transmitting one or parameters, performing function / s, communicating with other user devices and transmitting data to the other user devices. The user equipment may have a processor, a display, a memory, a battery and an input-means such as a hard keypad and / or a soft keypad. The user equipmentmay be capable of operating on any radio access technology including but not limited to IP-enabled communication, Zig Bee, Bluetooth, Bluetooth Low Energy, Near Field Communication, Z-Wave, Wi-Fi, Wi-Fi direct, etc. For instance, the user equipment may include, but not limited to, a mobile phone, smartphone, virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other device as may be obvious to a person skilled in the art for implementation of the features of the present disclosure.

[0052] Further, the user device may also comprise a “processor” or “processing unit” includes processing unit, wherein processor refers to any logic circuitry for processing instructions. The processor may be a general-purpose processor, a special purpose processor, a conventional processor, a digital signal processor, a plurality of microprocessors, one or more microprocessors in association with a Digital Signal Processing (DSP) core, a controller, a microcontroller, Application Specific Integrated Circuits, Field Programmable Gate Array circuits, any other type of integrated circuits, etc. The processor may perform signal coding data processing, input / output processing, and / or any other functionality that enables the working of the system according to the present disclosure. More specifically, the processor is a hardware processor.

[0053] Radio Access Technology (RAT) refers to the technology used by mobile devices / User Equipment (UE) to connect to a cellular network. It refers to the specific protocol and standards that govern the way devices communicate with base stations, which are responsible for providing the wireless connection. Further, each RAT has its own set of protocols and standards for communication, which define the frequency bands, modulation techniques, and other parameters used for transmitting and receiving data. Examples of RATs include a GSM (Global System for Mobile Communications), a Code Division Multiple Access (CDMA), a Universal Mobile Telecommunications System (UMTS), a Long-Term Evolution (LTE), a FifthGeneration (5G) technology, and a Sixth Generation (6G) technology. The choice of RAT depends on a variety of factors, including the network infrastructure, the available spectrum, and the mobile device's / device's capabilities. Mobile devices often support multiple RATs, allowing them to connect to different types of networks and provide optimal performance based on the available network resources.

[0054] Wireless communication technology has rapidly evolved over the past few decades. The first generation of wireless communication technology was analog, offering only voice services. Further, text messaging and data services became possible when a Second Generation (2G) technology was introduced. A Third Generation (3G) technology marked the introduction of high-speed internet access, mobile video calling, and location-based services. A Fourth Generation (4G) technology revolutionized the wireless communication with faster data speeds, improved network coverage, and security. Currently, the 5G technology is being deployed, offering significantly faster data speeds, lower latency, and the ability to connect many devices simultaneously. These advancements represent a significant leap forward from previous generations, enabling enhanced mobile broadband, improved Internet of Things (loT) connectivity, and more efficient use of network resources. The 6G technology promises to build upon these advancements, pushing the boundaries of wireless communication even further. While the 5G technology is still being rolled out globally, research and development into the 6G are rapidly evolving, with the aim of revolutionizing the way of connecting and interacting with technology. Currently, the 5G technology is being deployed, with even faster data speeds, low latency, and the ability to connect multiple devices simultaneously. The 6G technology promises to build upon these advancements, pushing the boundaries of wireless communication even further. Looking ahead, 6G technology promises to build upon these advancements, pushing the boundaries of wireless communication even further. As wireless communication technologies have rapidly evolved from 2Gto 6G and beyond, the complexity of telecommunication network deployments has increasedsignificantly. This evolution of wireless communication technologies ensure optimal telecommunication network performance and reliability in modern communication systems.

[0055] While considerable emphasis has been placed herein on the components and component parts of the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiment as well as other embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be interpreted merely as illustrative of the disclosure and not as a limitation.

[0056] In a distributed system, ensuring synchronized access to shared resources across multiple processes or services is critical for maintaining data integrity and system stability. Concurrent access to resources often leads to race conditions, data inconsistencies, and resource contention, which may degrade performance and compromise reliability. Coordinating tasks across distributed nodes presents significant challenges, particularly when node failures occur, potentially leaving resources in an inconsistent state and hindering system scalability.

[0057] Conventional distributed systems frequently rely on centralized locking mechanisms or database locks to manage resource access. However, conventional locking systems typically rely on centralized databases or operating system-level constructs such as mutexes or semaphores. These approaches often introduce performance bottlenecks, single points of failure, and operational limitations such as deadlocks, priority inversion, or resource starvation. Moreover, if the node holding the lock crashes, the resource may remain indefinitely locked, requiring manual intervention to resolve the issue.

[0058] To address these challenges, the present disclosure implements a lock management system that utilizes an external cache (such as Remote Dictionary Server (Redis)) to ensure synchronized access to shared resources. The lock management system allows only one process to access a resource at a time, thereby effectively preventing race conditions and maintaining data consistency. Further, the lock management system efficiently manages resource contention, coordinates tasks across distributed network nodes, and provides comprehensive tracking of lock-related metrics, such as the number of lock requests, successful acquisitions, and failures, for improved monitoring and troubleshooting. The use of a high-throughput, in-memory data store facilitates low-latency lock acquisition and release, enabling smooth coordination of distributed tasks without sacrificing system performance. Unlike traditional systems, this system avoids central bottlenecks and supports high availability, making it particularly well-suited for modern cloud-native and microservice-based deployments.

[0059] A key advantage of the present disclosure is its robust failure-handling capability. The lock management system ensures that locks are properly released even in the event of application or node failures, maintaining consistency across the distributed network environment. Additionally, the lock management system dynamically tracks lock-related metrics, such as the number of lock requests, successful acquisitions, and failures. These metrics may be used for monitoring, diagnostics, and troubleshooting purposes, thereby enhancing system observability and manageability.

[0060] The present disclosure integrates advanced distributed locking with the external cache, enabling synchronized access control while preserving system performance and scalability. This solution not only ensures that critical operations can be carried out without interference but also improves resilience by preventing indefinite locking scenarios caused by partial system failures. As a result, the present lockmanagement system offers a significant improvement over traditional locking mechanisms by combining simplicity, efficiency, robustness, and fault tolerance into a unified framework for distributed lock management.

[0061] Hence, there is a need to provide a method and a system that can address the shortcomings of existing solutions.

[0062] The various embodiments throughout the disclosure will be explained in more detail with reference to FIG. 1- FIG. 6.

[0063] FIG. 1 illustrates an exemplary network architecture (100) of a system (108) for implementing a lock management system in a distributed network environment (e.g., a network (106)), in accordance with an embodiment of the present disclosure.

[0064] As illustrated in FIG. 1, the network architecture (100) may include one or more user equipments (UEs) (104-1, 104-2... 104-N) associated with one or more users (102-1, 102-2... 102 -N) in an environment. A person of ordinary skill in the art will understand that one or more users (102-1, 102-2... 102-N) may collectively referred to as the users (102). Similarly, a person of ordinary skill in the art will understand that one or more UEs (104-1, 104-2... 104-N) may be collectively referred to as the UE (104). Although only three UEs (104) are depicted in FIG. 1, however, any number of the UE (104) may be included without departing from the scope of the ongoing description.

[0065] In an embodiment, the UE (104) may include smart devices operating in a smart environment, for example, an Internet of Things (loT) system. In such an embodiment, the UE (104) may include, but is not limited to, smartphones, smart watches, smart sensors (e.g., mechanical, thermal, electrical, magnetic, etc.), networked appliances, networked peripheral devices, networked lighting system, communication devices, networked vehicle accessories, networked vehicular devices,smart accessories, tablets, smart television (TV), computers, smart security system, smart home system, other devices for monitoring or interacting with or for the users (102) and / or entities, or any combination thereof. A person of ordinary skill in the art will appreciate that the UE (104) may include, but not limited to, intelligent, multisensing, network- connected devices, that may integrate seamlessly with each other and / or with a central server or a cloud- computing system or any other device that is network-connected.

[0066] Additionally, in some embodiments, the UE (104) may include, but is not limited to, a handheld wireless communication device (e.g., a mobile phone, a smartphone, a tablet device, and so on), a wearable computer device (e.g., a headmounted display computer device, a head-mounted camera device, a wristwatch computer device, and so on), a Global Positioning System (GPS) device, a laptop computer, a tablet computer, or another type of portable computer, a media playing device, a portable gaming system, and / or any other type of computer device with wireless communication capabilities, and the like. In an embodiment, the UE (104) may include, but are not limited to, any electrical, electronic, electromechanical, or equipment, or a combination of one or more of the above devices, such as virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other computing device, wherein the UE (104) may include one or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as a camera, an audio aid, a microphone, a keyboard, and input devices for receiving input from the user (102) or the entity such as touchpad, touch-enabled screen, electronic pen, and the like. A person of ordinary skill in the art will appreciate that the UE (104) may not be restricted to the mentioned devices and various other devices may be used.

[0067] Referring to FIG. 1, the UE (104) may communicate with a system (108) through a network (wireless communication network) (106) for sending orreceiving various types of data. In an embodiment, the network (106) may include at least one of a fifth generation (5G) network, sixth generation (6G) network, or the like. The network (106) may enable the UE (104) to communicate with other devices in the network architecture (100) and / or with the system (108). The network (106) may include a wireless card or some other transceiver connection to facilitate this communication. In another embodiment, the network (106) may be implemented as, or include any of a variety of different communication technologies such as a wide area network (WAN), a local area network (LAN), a wireless network, a mobile network, a Virtual Private Network (VPN), the Internet, the Public Switched Telephone Network (PSTN), or the like.

[0068] In an embodiment, the network (106) may include, by way of example but not limitation, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth. The network (106) may also include, by way of example but not limitation, one or more of a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet- switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public-Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, or some combination thereof.

[0069] In an embodiment, the UE (104) is communicatively coupled with the network (106). The network (106) may receive a connection request from the UE (104). The network (106) may send an acknowledgment of the connection request to the UE (104). The UE (104) may transmit a plurality of signals in response to the connection request.

[0070] In an embodiment, the network architecture (100) may include a server (110). The server (110) may include the system (108). The server (110) may manageresources, processes requests, and provides services across the distributed network environment. The server (110) manages resources like files, databases, or computational tasks and ensures that resources are available and accessible to users (e.g., user (102)). In an aspect, the server (110) may receive one or more requests for performing locking management via a user interface of the UE (104). The one or more requests may include a Hypertext Transfer Protocol (HTTP) request, a Simple Mail Transfer Protocol (SMTP) request, and Simple Network Management Protocol (SNMP) request.

[0071] In an embodiment, the network architecture (100) may include an external cache (112). The external cache (112) may be coupled with the system (108). The external cache (112) is a memory that stores frequently accessed data to improve performance and reduce latency. The external cache (112) may be placed outside of the primary data store or database and holds copies of lock details that are computationally expensive to retrieve. For example, the external cache (112) may store the lock details that may include various data types such as a string, a hash, a list, a set and a sorted set.

[0072] Although FIG. 1 shows exemplary components of the network architecture (100), in other embodiments, the network architecture (100) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 1. Additionally, or alternatively, one or more components of the network architecture (100) may perform functions described as being performed by one or more other components of the network architecture (100).

[0073] FIG. 2 illustrates an exemplary block diagram (200) of the system (108) for implementing the lock management system in the distributed network environment, in accordance with an embodiment of the present disclosure. FIG. 2 is explained in conjunction with FIG. 1. In an embodiment, the lock management system may refer toa distributed locking mechanism that utilizes the external cache 112 to ensure synchronized access to shared resources across multiple nodes, efficiently managing resource contention, coordinating tasks, and providing robust failure handling to maintain system stability and scalability.

[0074] In an embodiment, the system (108) may include one or more processor(s) (202). The one or more processor(s) (202) may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, logic circuitries, and / or any devices that process data based on operational instructions. Among other capabilities, the one or more processor(s) (202) may be configured to fetch and execute computer-readable instructions stored in a memory (204) of the system (108). The memory (204) may be configured to store one or more computer-readable instructions or routines in a non-transitory computer readable storage medium, which may be fetched and executed to create or share data packets over a network service. The memory (204) may include any non-transitory storage device including, for example, volatile memory such as random-access memory (RAM), or non-volatile memory such as erasable programmable read only memory (EPROM), flash memory, and the like.

[0075] In an embodiment, the system (108) may include an interface(s) (206). The interface(s) (206) may include a variety of interfaces, for example, interfaces for data input and output devices (VO), storage devices, and the like. The interface(s) (206) may facilitate communication through the system (108). The interface(s) (206) may also provide a communication pathway for one or more components of the system (108). Examples of such components include, but are not limited to, a processing engine (208) and a database (222). The processing engine (208) may include various modules, such as a receiving module (210), a determining module (212), a creating module (214), an acquiring module (216), a releasing module (218), and an updating module (220). The database (222) includes data that may be either stored or generatedas a result of functionalities implemented by any of the components of the processor (202) or the processing engine (208).

[0076] In an embodiment, the processing engine (208) may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processing engine (208). In the examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processing engine (208) may be processor-executable instructions stored on a non- transitory machine-readable storage medium. The hardware for the processing engine (208) may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the machine-readable storage medium may store instructions that, when executed by the processing resource, implement the processing engine (208). In such examples, the system (108) may comprise the machine-readable storage medium storing the instructions and the processing resource to execute the instructions, or the machine-readable storage medium may be separate but accessible to the system and the processing resource. In other examples, the processing engine (208) may be implemented by electronic circuitry.

[0077] In an embodiment, the processing engine (208) may be configured to perform a locking mechanism in the distributed network environment using various modules (e.g., modules 210 - 220) of the system (108). Themodules (210 - 220) include logic for acquiring, maintaining, and releasing locks, ensuring that only one process may access a resource at a time. The processing engine (208) also interacts with the external cache (112) to manage the locks efficiently.

[0078] The processing engine (208) may be associated with one or more application instances. The one or more application instances may be a microservice, a container, or an application running across a distributed computing environment (e.g.,the distributed network environment). The one or more application instances may include, for example, service instances for task coordination, database instances for data storage, or computing instances for processing lock requests. Each of the application instances may work to perform tasks, process data, or provide services in the distributed computing environment. In an aspect, the application instances may be microservices that are configured to perform a specific function or handle a specific aspect of the application. For example, a customer feedback application may have separate microservices for user authentication, user feedback, and user notification. The user feedback microservice may be configured to record a rating and score, a textual comment, and a user demographic.

[0079] In order to implement the lock management system, initially, the receiving module (210) is configured to receive a request from a network node associated with the distributed network environment. The request may be received to create a lock for a resource on which at least one operation is to be performed. In an embodiment, the at least one operation includes one of a create operation, a modify operation, and a delete operation on the requested resource. The create operation may involve generating a new entry in a database or initializing a new file or configuration object. Further, the modify operation may involve updating existing attributes, parameters, or content of a resource, such as altering user details in a record or changing system settings in a configuration file. Further, the delete operation may involve removing obsolete or invalid resources from the system, such as deleting a file or clearing a temporary session.

[0080] The resource may include, but is not limited to, a record (e.g., a user profile or trouble ticket in a database), a file (e.g., a log file or configuration file), a configuration (e.g., a service parameter or system setting), or a data entity (e.g., an object, cached structure, or session state). The locking mechanism ensures that only one application instance may perform operations on a given resource at a time, therebypreventing race conditions, stale updates, and data corruption in the distributed environment.

[0081] In an embodiment, the request may be initiated by an application instance, microservice, or a UE (e.g., UE 104) interacting with the system (108) through a client interface or an Application Programming Interface (API) gateway. For example, the request may include an HTTP POST request to create a lock for modifying a user profile in a customer database, a service call to create a lock for updating configuration parameters of a running application instance, a REST API request to create a lock for submitting user feedback or create a support ticket, and a transactional request to write data to a shared record or file.

[0082] The determining module (212) is configured to determine whether the lock for the requested resource already exists, for example, in a memory of the distributed network environment. In an embodiment, the memory is a cache memory (e.g., external cache (112)) located in the distributed network environment. During the lock management process, the determining module (212) queries the external cache (112) using a unique identifier (e.g., key) associated with the requested resource. The purpose of this check is to determine whether a lock entry already exists for that resource. If a valid lock is found in the external cache (112), indicating that another application instance has already acquired access.

[0083] Upon determining that the lock does not exist (i.e., the resource is currently available for access), the creating module (214) is configured to create a new lock for the requested resource. The creation process includes generating a lock entry in the external cache (112), associating it with a resource’s identifier, setting the lock status as active or acquired and defining an expiration time to avoid stale locks in case of failures. The mechanism ensures that only one application instance may proceed with operations on the resource at a time, thereby preserving data consistency and preventing concurrent access issues across the distributed environment.

[0084] In an embodiment, the determining module (212) is further configured to detect a failure to create the new lock in the memory. The failure may arise due to issues such as communication timeout with the external cache (112), write conflicts, or internal errors within the lock creation process. If such failure is detected by the determining module (212) while creating the new lock in the memory, the creating module (214) is configured to retry the creation of the new lock for a predefined number of attempts. During each retry, the determining module (212) attempts to reestablish the lock entry in the external cache (112) by validating resource availability and writing the lock. If the creation of the new lock remains unsuccessful after exhausting the allowed number of retries (e.g., for the predefined number of attempts), the releasing module (218) releases the lock for the requested resource that already exists in the memory.

[0085] Upon creating the new lock for the requested resource, the creating module (214) stores details of the new lock in the memory (e.g., cache memory). The detail of the created lock includes, for example, a unique identifier (ID) associated with the requested resource and an expiration time for the newly created lock.

[0086] The acquiring module (216) is configured to acquire the new lock for a predefined time period. The predefined time period ensures that the lock is automatically released if the lock holder fails to explicitly release it, thereby preventing indefinite locking due to unexpected failures. Upon successful acquisition of the lock, the corresponding application instance may proceed to perform at least one operation on the requested resource, such as creating, modifying, or deleting the resource content.

[0087] In an embodiment, after completing the operation on the requested resource, the receiving module (210) is configured to receive an unlock request corresponding to the acquired new lock from at least one application platform (e.g., application instance). The unlock request serves as an explicit instruction to release the lock and make the resource available for access by other instances. In response to1 receiving this unlock request, the releasing module (218) releases the lock associated with the requested resource by updating or removing the lock entry from the external cache (112). This lock release operation ensures synchronized access and efficient resource utilization within the distributed network environment.

[0088] The updating module (220) is configured to update a status of the newly acquired lock in the memory. The status is one of an available status of the new lock and an unavailable status of the new lock. In an embodiment, the available status indicates that no application instances are currently holding the lock for the requested resource, and the resource is free to be acquired by any requesting entity. The unavailable status indicates that the lock has been acquired by the application instances, and the resource is currently in use and not available for performing creation / modification / deletion operations.

[0089] In an embodiment, the updating module (220) is also configured to maintain a counter for each request received for creating the new lock, each unlock request for releasing the new lock, each successful acquisition of the new lock for the requested resource, successful lock updates in the memory, successful lock release and successful record deletion from the memory.

[0090] Further, if no application instances are waiting for the resource, then the processing engine (208) may initiate a deletion of the lock details from the external cache (112). The deletion of unused lock details from the external cache ensures proper clean-up of the external cache (112) to maintain the stability and efficiency of the process.

[0091] For the sake of explanation, consider an example of a distributed lock request in a radio access network. A Distributed Unit (DU) (e.g., DU_A), sends a request to a central or peer coordination controller (receiving module (210)) to create a lock on a specific spectrum slice, SI. This request is made in preparation for ascheduled uplink transmission from the UE, and the purpose of the lock is to prevent transmission collisions with other DUs operating in adjacent cells.

[0092] Upon receiving the request, the determining module (212) checks the external cache (112), which serves as a shared memory or distributed lock registry, to determine whether the spectrum slice SI is already locked by another DU (e.g., DU B). If no existing lock is found, the creating module (214) proceeds to create a new lock for spectrum slice SI.

[0093] Once the lock is successfully created, the creating module (214) stores the lock details in the external cache (112). The created lock includes metadata such as the resource (spectrum slice SI), The lock holder (DU_A), the intended lock duration (e.g., 5 milliseconds), and the operational purpose (uplink transmission for UE 123). The acquiring module (216) then grants DU_A exclusive access to spectrum slice SI for the predefined time window, typically aligned with the 5ms transmission time interval used in radio scheduling. After this time period, the lock may be automatically released or manually unlocked by DU_A to make the spectrum slice available for subsequent use by other DU.

[0094] FIG. 3 illustrates an exemplary system architecture (300) for implementing the lock management system in the distributed network environment, in accordance with an embodiment of the present disclosure. FIG. 3 is explained in conjunction with FIGS. 1 and 2.

[0095] In an embodiment, the system (108) includes one or more application instances (302-1, 302-2...302-N). In an alternative embodiment, multiple systems (108-1,108-2... 108-N) may be associated with the one or more application instances (302-1, 302-2... 302-N) to form a distributed network environment. In such an embodiment, each of the systems may be located at different geographic locations, for example, the system (108-1) may be placed in Mumbai, and the system (108-2) maybe placed in Delhi. The systems (108-N) may be connected via the network (106) to perform a locking mechanism from different geographic locations in the distributed network environment. For example, the one or more application instances (302-1, 302- 2... 302-N) (collectively referred to as the application instances 302) initiate a locking mechanism to acquire a lock for a resource, such as a data resource, from different geographic locations.

[0096] In an embodiment, the system (108) may be coupled with the external cache (112). The external cache (112) may be configured to store the frequently used user data within the distributed network environment. The external cache (112) may enhance the performance of the system (108) by reducing the data fetching time from the database (222). For example, the external cache (112) may store one or more lock details. The lock details may include a key and a value. The key may be a resource ID. The resource ID may be a unique identifier to identify the resource. The value may include an instance ID and an expiration time. For example, the instance ID may be a unique identifier given to the application instance (302) that requested a lock on the resource. The application instances (302) may access the external cache (112) to retrieve the lock details that may reduce the time taken to retrieve lock details from the database (222). The external cache (112) may handle a large volume of requests and distribute the requests across the distributed computing environment (e.g., the distributed network environment). In an aspect, the external cache (112) may be a level 2 (L2) cache. The L2 cache may be separate from a main memory.

[0097] In an embodiment, the system (108) sends a request to the external cache (112) via the application instances (302). The request may be associated with creating and acquiring a lock for a resource on which at least one operation is to be performed. The at least one operation includes one of a create operation (e.g., adding new resource entries), a modify operation (e.g., updating existing data), and a delete operation (e.g., removing outdated or unnecessary records) on the requested resource.

[0098] In an embodiment, the system (108) may be configured to initialize the application instances (302) to manage lock operations. The lock operations may include a lock creation, a lock acquisition, and a lock release of the requested resource. In an aspect, the lock creation may be a process that restricts access to a resource to ensure that only one application instance (process, thread, or node) may access the resource at a time. The lock acquisition may be a process where an application instance gets access to the requested resource by registering the lock in the external cache (112). The lock release may be a process of releasing the acquired lock once the intended operation on the resource is complete. This ensures that other application instances waiting for access may attempt to acquire the lock, thereby maintaining synchronized and orderly access to shared resources.

[0099] In an embodiment, the locking mechanism may be performed by triggering the application instances (302). The application instances (302) may be triggered via one or more requests such as the HTTP request from the UE (104). For example, a network node (UE or computing device) in the distributed computing environment may request the one or more application instances to modify a user trouble ticket in the database (222). The application instances (302) may check for the availability of a resource related to the user trouble ticket. For example, the resource may be a computational resource, a storage resource, or a configuration resource. Based on the availability of the resource, the processing engine (208) may initiate a lock mechanism to acquire a lock on the resource.

[0100] In an embodiment, a counter may be used to track and count the requests sent to the external cache (112). For example, if the system (108) sends 8 requests to the external cache (112) to acquire or manage a lock, the counter may store the value as 8. The counter facilitates monitoring of cache interactions, helps in diagnosing performance or contention issues, and enables detailed analysis for system optimization.

[0101] In an embodiment, the system (108) may verify if the lock already exists for the requested resource based on the lock details stored in the external cache (112). If one of the application instances (302) has acquired the lock on the resource, then the other application instance may wait or retry till the acquired lock is released.

[0102] In an embodiment, the application instances (302) may acquire the lock for the requested resource via the external cache (112). The lock may be acquired on the resource with an expiration time. For example, the expiration time may be a second, a minute, an hour, etc. The expiration time represents a time after which the resource is released automatically if the resource is in a locked state and usage of the resource is complete. In an embodiment, upon setting the expiration time, the processing engine (208) may be configured to check with the application instances (302) whether a task involving the requested resource is completed. In an exemplary aspect, the application instances (302) may use a flag to indicate the status of the resource usage. The flag may be set to “TRUE”, if the requested resource is in use at the application instances (302). Otherwise, the flag may be set to “FALSE”, if the task involving the requested resource is complete. The flag status may be stored in the external cache (112).

[0103] The system (108) may check the flag status of the resource to acquire the lock. If the resource is already acquired by one of the application instances (302), the other application instance (302) may be configured to wait or retry via a backoff strategy to acquire the resource. For example, the backoff strategy may involve initiating a retry mechanism to acquire the lock on the resource. The locking module provides a retry mechanism which involves retrying to establish a connection between the application instances (302) and the external cache (112) to obtain the lock details of the resource. The retry mechanism may be initiated in a configured time interval. The configured time interval may be a second, a minute, an hour, etc.

[0104] In an aspect, the retry mechanism may involve trying to acquire the lock on the requested resource stored in the external cache (112). The retry mechanism maybe initiated when the lock is already acquired by one of the application instances (302) and the other application instances (302) request to acquire the lock on the resource. The other application instances (302) may retry to acquire the lock on the resource by sending one or more requests, such as an HTTP request, in the configured interval.

[0105] In an embodiment, the system (108) may check whether the lock is registered in the external cache (112). Upon verifying that the lock is unregistered, the system (108) may attempt to create a lock record in the external cache (112). For example, if the lock creation is successful, the lock status is updated in the cache to reflect its presence in the cache. If the lock creation is unsuccessful after retries, it handles the failure by releasing the lock and notifying the application instances (302) of the failure.

[0106] In an embodiment, the system (108) may update the external cache (112) with lock details and timestamps once the lock is acquired. The system (108) may store the lock details such as a resource ID, a lock type, a lock acquirer, and a lock status. The timestamp may include a time and a date.

[0107] In an embodiment, the availability of the requested resource may be determined based on the lock status. The lock details are stored in the external cache (112). For example, the lock status may be set as available, then the resource may be ready for acquiring. Further, the system (108) may track and count successful lock acquisitions using a lock counter. The lock counter indicates the number of times the application instances (302) request to acquire the lock on the resource. For example, the application instances (302) may have requested the external cache (112) for 5 times to acquire the lock on the resource. The lock counter may store the value as 5.

[0108] In an embodiment, the application instances (302) may send a release request to the external cache (112) for releasing the lock for the resource. For example, the release request may include a resource ID. The external cache (112) parses recordsof the lock details based on the resource ID. If the external cache (112) matches the received resource ID with the resource ID stored in the external cache (112), the external cache (112) may delete the lock details related to the resource ID.

[0109] In an embodiment, the system (108) may check if application instances (302) are waiting for the lock. The system (108) may also delete the lock details from the external cache (112) when the resource is not being acquired by any application instance after the expiration time.

[0110] In an embodiment, the system (108) may remove the lock entry from the external cache (112) if no other application instances (302) are waiting for the lock. The system (108) may ensure proper clean-up of lock details from the external cache (112) to maintain system (108) stability and efficiency.

[0111] FIG. 4 illustrates an exemplary flow diagram of a method (400) for implementing the locking management system in the distributed network environment, in accordance with an embodiment of the present disclosure. FIG. 4 is explained in conjunction with FIGS. 1, 2, and 3. In an embodiment, each step of the method (400) may be performed by various modules (e.g., the receiving module (210), the determining module (212), the creating module (214), the acquiring module (216), the releasing module (218), and the updating module (220)) of the processing engine (208) to perform the locking mechanism in the distributed network environment.

[0112] At step 402, the processing engine (208) initiates a process for implementing a lock management system (also referred to as the locking mechanism) in the distributed network environment.

[0113] At step 404, the processing engine (208) may send a request to the external cache (112) (e.g., a request to create a lock for a resource on which the operation is to be performed). The operation may include a read operation, a write operation, or a delete operation on the resource. In an aspect, the processing engine(208) may send the request along with a key and an expiration time. The key may be a unique identification for the resource stored in the database (222). For example, the key may be a resource ID. The processing engine (208) may set the expiration time for locking the resource by the requested application instance (302). The expiration time may be a second, a minute, or an hour. The expiration time may be set for the resource usage. For example, the expiration time may be set as 2 minutes, which implies the application instances (302) may use the resource for 2 minutes.

[0114] At step 406, the processing engine (208) may check whether the lock is already acquired for the requested resource from the external cache (112). The external cache (112) may store a lock detail of a plurality of resources. The plurality of resources may include, but are not limited to, a computational resource, a data resource, a service resource, and a network resource. In an aspect, the lock details may include, but are not limited to, a resource ID, a lock status, a lock type, and a duration. For example, the lock type may include a blocking and a non-blocking. The blocking lock may not allow any other application instances other than the acquired application instance to access the resource until the process is complete at the application instances (302). The lock details are stored in the external cache (112).

[0115] In an aspect, the processing engine (208) may parse a response from the external cache (112) to verify a status of the lock on the requested resource. The processing engine (208) may retrieve the resource ID from the received lock request. The resource ID may be a unique key for identifying details of the requested resource from the external cache (112). For example, the external cache (112) may store the lock details in a table format. The table format may include a plurality of rows and columns. One of the rows may store the resource ID. The processing engine (208) may compare, and match the received resource ID via request and the stored resource ID. If the received resource ID matches the stored resource ID, then the lock is already acquired for the requested resource. Otherwise, the processing engine (208) create a lock for therequested resource and stores the lock details in the external cache (112). In an aspect, the processing engine (208) may perform a polling mechanism to check the status of the lock on the requested resource. The polling mechanism involves making repeated requests at fixed intervals to check the availability of the resource. The fixed intervals may be a second, a minute, an hour, etc.

[0116] At step 408, the processing engine (208) may initiate a wait or retry process, if the lock is not acquired on the resource by the application instances (302). The wait or retry process may represent a backoff strategy. In an aspect, the backoff strategy may be used for managing retries and handling transient failures to avoid exacerbating the problem in lock acquiring. The backoff strategy may include a fixed backoff, a linear backoff, an exponential backoff, and an adaptive backoff. The backoff strategy involves performing a retry mechanism to acquire the lock. The retry mechanism may be a process of sending a lock request to the external cache at a periodical interval. For example, the periodic interval may be 5 minutes. In one aspect, the fixed backoff strategy may be a simple retry mechanism that involves sending a request for the lock at a fixed interval. For example, the fixed interval is a constant time that is configured during the initiation of the fixed backoff strategy. The constant time may be set as 10 minutes at the time of initiation. In another aspect, the linear backoff strategy may involve increasing a waiting time in a linear manner to initiate the retry mechanism. The waiting time refers to the duration for which the processing engine (208) pauses before enabling the retry mechanism. For example, if the initial waiting time is 2 seconds, the next waiting time may be 4 seconds, 6 seconds, etc.

[0117] In another aspect, the exponential backoff strategy may be used to manage repeated attempts to acquire the lock on the resource. The exponential backoff strategy involves sending the lock request to acquire the resource based on the waiting time calculated by an exponential function. For example, the exponential function calculates the waiting time based on the number of attempts made to acquire theresource. For example, if the number of attempts made is 2, the waiting time may be set as 4 seconds, and if the number of attempts made is 3, the waiting time may be set as 8 seconds. In another aspect, the adaptive backoff strategy involves adjusting the waiting time according to various metrics such as a frequency of failure, a processor load, and a latency. The waiting time may be modified or adapted based on the various metrics.

[0118] In an aspect, the processing engine (208) may monitor a waiting queue stored in the memory (204). The waiting queue may be used to manage requests, or processes that are waiting for access to the acquired resource. For example, the application instance (302-1) may have acquired a resource- A, and the application instance (302-2) may be placed in the waiting queue to indicate it as the next acquirer. The application (302-2) may wait in the waiting queue to acquire the resource- A till the application instance (302-1) releases the resource.

[0119] In an exemplary aspect, the backoff strategy may be a process of periodically retrying to acquire the lock on the requested resource via the external cache (112). The number of successful and unsuccessful tries to acquire the lock may be counted and tracked using a flag and a counter. The flag may represent a lock status. For example, if the lock is acquired, i.e., if the requested resource is in use at the application instances (302), the flag may be set to “TRUE”. Otherwise, the flag may be set to “FALSE” if the task involving the requested resource is completed. The counter may represent a number of attempts initiated to acquire the lock. For example, the counter may keep track of a count or number of occurrences of failure in acquiring the lock. If the number of occurrences of failure is 5, the counter may be set to 5.

[0120] At step 410, the processing engine (208) may trigger a release request for the resource if the lock is acquired by the application instances (302) on the resource. The release request may be initiated by the application instances (302) (e.g., application platform) if the task involving the resource is completed or the acquiredresource has attained the lock expiration time. In an aspect, the lock may be released based on the release request. In an aspect, the release request may be a HTTP request. The release request may include a key. The key may be a unique identifier to identify the resource. For example, the key may be a resource ID. For example, the resource ID may be represented as Resource ID: TN123A. In an exemplary aspect, the release request may delete the lock details in the external cache (112). The deletion of the lock details in the external cache (112) may ensure that the resource is available for the next lock acquisition. In an aspect, if the same application instance requests the same resource from the external cache (112). In such scenarios, the external cache (112) may not delete the lock details.

[0121] In an aspect, the resource may be released if the request for lock fails to acquire the lock more than a threshold number of times. For example, if the threshold value is 5 and the request initiated to acquire the lock is unsuccessful in acquiring the lock for 5 times, then the requested resource is released. The release of the resource may also be determined by a lock expiration time. The lock expiration time may be a second, a minute, an hour, etc. For example, the lock expiration time may be 15 minutes. In case the resource is not used for the lock expiration time, the lock is released.

[0122] At step 412, the processing engine (208) may terminate the locking mechanism in the distributed network environment. In an aspect, the processing engine (208) may ensure that no application instances (302) need to wait for the lock on the requested resource for an indefinite time. For example, the processing engine (208) may check the waiting queue to ensure no other application instances (302) require the resource. Further, if no application instances (302) are waiting for the resource, then the processing engine (208) may initiate a deletion of the lock details from the external cache (112). The deletion of unused lock details from the external cache ensures properclean-up of the external cache (112) to maintain the stability and efficiency of the process.

[0123] FIG. 5 illustrates another exemplary flow diagram of a method (500) for implementing the locking management system in the distributed network environment, in accordance with an embodiment of the present disclosure. In an embodiment, each step of the method (500) may be performed by various modules (e.g., the receiving module (210), the determining module (212), the creating module (214), the acquiring module (216), the releasing module (218), and the updating module (220)) of the processing engine (208).

[0124] At step 502, the receiving module receives a request from a network node associated with the distributed network environment to create a lock for a resource on which at least one operation is to be performed. In an embodiment, the at least one operation includes one of a create operation, a modify operation, and a delete operation on the requested resource. The resource may include, but is not limited to, a record, a file, a configuration, or a data entity.

[0125] At step 504, the determining module (212) determines whether the lock for the requested resource already exists in a memory of the distributed network environment. In an embodiment, the memory is a cache memory (e.g., external cache 112) located in the distributed network environment. Upon determining that the lock does not exist, the creating module (214) is configured to create a new lock for the requested resource. In an embodiment, if a failure is detected by the determining module (212) while creating the new lock in the memory, the creating module (214) retries the creation of the new lock for a predefined number of attempts. Upon unsuccessful creation of the new lock after the predefined number of attempts, the releasing module (218) releases the lock for the requested resource that already exists in the memory.

[0126] At step 506, upon creating the new lock for the requested resource, the creating module (214) stores details of the new lock in the memory. The detail of the created lock includes a unique identifier (ID) associated with the requested resource and an expiration time for the created new lock.

[0127] At step 508, the acquiring module (216) acquires the new lock for a predefined time period. In an embodiment, upon acquiring and performing the at least one operation on the requested resource, the receiving module (210) is configured to receive an unlock request corresponding to the acquired new lock from at least one application platform. In response to receiving the unlock request, the releasing module (218) releases the newly acquired lock from the requested resource.

[0128] At step 510, the updating module (220) updates a status of the newly acquired lock in the memory. The status is one of an available status of the new lock and an unavailable status of the new lock. In an embodiment, the updating module (220) is also configured to maintain a counter for each request received for creating the new lock, each unlock request for releasing the new lock, each successful acquisition of the new lock for the requested resource, successful lock updates in the memory, successful lock release and successful record deletion from the memory.

[0129] In an overall aspect, to implement the lock management system in the distributed network environment, the method 400 may consider the following statements:

[0130] Initialize system components: Initialize components (e.g., various modules of the processing engine 208) to manage lock operations, such as lock creation, acquisition, and release.

[0131] Receive lock request: A system node (e.g., a network node) requests a lock for a specific resource. Track and count the total number of lock requests received.

[0132] Check lock existence: Verify if the lock already exists for the requested resource. If not, create a new lock entry and add it to the lock management system.

[0133] Acquire lock: Attempt to acquire the lock for the resource. Track and count successful lock acquisitions.

[0134] Perform pre-lock operations: If the lock is not registered in the external cache (112), attempt to create a lock record in the external cache (112). If successful, update the lock status to reflect its presence in the external cache (112). If unsuccessful after retries, handle the failure by releasing the lock and notifying the system (108).

[0135] Update lock status: Once the lock is acquired, update the external cache (112) with lock details and timestamps. Track and count successful lock updates in the cache.

[0136] Receive unlock request: The system node requests to release the lock for the resource. Track and count the total unlock requests received.

[0137] Release lock: Release the lock for the resource. Track and count successful lock releases.

[0138] Perform post-unlock operations: If no other threads are waiting for the lock, delete the lock record from the external cache (112). Track and count successful lock deletions from the external cache (112).

[0139] Clean up: Remove the lock entry from the system (108) if no threads are waiting for the lock. Ensure proper clean-up of resources to maintain system stability and efficiency.

[0140] FIG. 6 illustrates an example computer system (600) in which or with which the embodiments of the present disclosure may be implemented.

[0141] As shown in FIG. 6, the computer system (600) may include an external storage device (610), a bus (620), a main memory (630), a read-only memory (640), a mass storage device (650), a communication port(s) (660), and a processor (670). A person skilled in the art will appreciate that the computer system (600) may include more than one processor and communication ports. The processor (670) may include various modules associated with embodiments of the present disclosure. The communication port(s) (660) may be any of an RS-232 port for use with a modembased dialup connection, a 10 / 100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fiber, a serial port, a parallel port, or other existing or future ports. The communication ports(s) (660) may be chosen depending on a network, such as a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system (600) connects.

[0142] The main memory (630) may be Random Access Memory (RAM), or any other dynamic storage device commonly known in the art. The read-only memory (640) may be any static storage device(s) e.g., but not limited to, a Programmable Read Only Memory (PROM) chip for storing static information e.g., start-up or basic input / output system (BIOS) instructions for the processor (670). The mass storage device (650) may be any current or future mass storage solution, which can be used to store information and / or instructions. Exemplary mass storage solutions include, but are not limited to, Parallel Advanced Technology Attachment (PAT A) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and / or Firewire interfaces).

[0143] The bus (620) may communicatively couple the processor(s) (670) with the other memory, storage, and communication blocks. The bus (620) may be, e.g. a Peripheral Component Interconnect PCI) / PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), Universal Serial Bus (USB), or the like, for connectingexpansion cards, drives, and other subsystems as well as other buses, such a front side bus (FSB), which connects the processor (670) to the computer system (600).

[0144] Optionally, operator and administrative interfaces, e.g., a display, keyboard, and cursor control device may also be coupled to the bus (620) to support direct operator interaction with the computer system (600). Other operator and administrative interfaces can be provided through network connections connected through the communication port(s) (660). Components described above are meant only to exemplify various possibilities. In no way should the aforementioned exemplary computer system (600) limit the scope of the present disclosure.

[0145] In an exemplary embodiment, the present disclosure discloses a computer program product comprising a non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform a method for implementing a locking management system in a distributed network environment. The method includes receiving a request from a network node associated with the distributed network environment to create a lock for a resource on which at least one operation is to be performed. The method further includes determining whether the lock for the requested resource already exists in a memory of the distributed network environment. Upon determining that the lock does not exist, the method further includes creating a new lock for the requested resource. The method includes storing details of the new lock in the memory. The method includes acquiring the new lock for a predefined time period. The method further includes periodically updating a status of the acquired new lock in the memory.

[0146] The method and system of the present disclosure may be implemented in a number of ways. For example, the methods and systems of the present disclosure may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order for the steps of the method is for illustration only, and the steps of the method of the present disclosure are not limitedto the order specifically described above unless specifically stated otherwise. Further, in some embodiments, the present disclosure may also be embodied as programs recorded in a recording medium, the programs including machine-readable instructions for implementing the methods according to the present disclosure. Thus, the present disclosure also covers a recording medium storing a program for executing the method according to the present disclosure.

[0147] While the foregoing describes various embodiments of the invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof. The scope of the invention is determined by the claims that follow. The invention is not limited to the described embodiments, versions or examples, which are included to enable a person having ordinary skill in the art to make and use the invention when combined with information and knowledge available to the person having ordinary skill in the art.

[0148] The method and system of the present disclosure may be implemented in a number of ways. For example, the methods and systems of the present disclosure may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order for the steps of the method is for illustration only, and the steps of the method of the present disclosure are not limited to the order specifically described above unless specifically stated otherwise. Further, in some embodiments, the present disclosure may also be embodied as programs recorded in a recording medium, the programs including machine-readable instructions for implementing the methods according to the present disclosure. Thus, the present disclosure also covers a recording medium storing a program for executing the method according to the present disclosure.

[0149] While considerable emphasis has been placed herein on the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from theprinciples of the disclosure. These and other changes in the preferred embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be implemented merely as illustrative of the disclosure and not as a limitation.

[0150] The present disclosure offers significant technical advancements in implementing a locking management system in a distributed network environment. These advancements overcome the limitations of existing solutions by implementing a scalable and fault-tolerant lock management system that leverages an external cache, such as Redis, to coordinate access to shared resources across multiple network nodes. The disclosure involves a distributed locking mechanism using an external in-memory cache, dynamic retry logic for lock creation, robust failure handling, and real-time lock status tracking, which offer significant improvements in system scalability, operational efficiency, and fault tolerance. By implementing a cache-based locking architecture, the disclosure enhances synchronized resource access across distributed application instances, resulting in reduced latency, minimized contention, and improved system stability even in the event of node failures. This solution eliminates common issues associated with traditional locking methods, such as centralized bottlenecks, indefinite locking due to crashes, and excessive manual intervention, thereby ensuring reliable, high-performance operation in a large-scale distributed environment.ADVANTAGES OF THE PRESENT DISCLOSURE

[0151] The present disclosure provides a method and a system for implementing a locking management system in a distributed network environment.

[0152] The present disclosure provides a method and a system that prevent conflicting changes and maintain data integrity by ensuring that only one process can modify a resource at a time.

[0153] The present disclosure provides a method and a system that manages access to shared resources efficiently to avoid resource contention and optimize resource usage.

[0154] The present disclosure provides a method and a system that coordinates tasks across multiple nodes in a controlled and orderly manner to ensure smooth functioning of the distributed computing environment (e.g., the distributed network environment).

[0155] The present disclosure provides a method and a system that handles process failures by ensuring that the locks are properly released, and the distributed computing environment remains stable.

[0156] The present disclosure provides a method and a system that efficiently manages the locks and reduces unnecessary retries for locking resources to optimize performance and improve resource utilization.

[0157] The present disclosure provides a method and a system that includes an application programming interface (API) for acquiring and releasing locks to eliminate the complexities of concurrency management and make it easier to develop distributed applications.

[0158] The present disclosure provides a method and a system that allows for a configuration of custom locking policies and retry mechanisms, providing flexibility to meet specific application needs.

Claims

We claim:

1. A method (500) for implementing a lock management system in a distributed network environment, the method (500) comprising: receiving (502), by a receiving module (210), a request from a network node associated with the distributed network environment to create a lock for a resource on which at least one operation is to be performed; determining (504), by a determining module (212), whether the lock for the requested resource already exists in a memory of the distributed network environment; upon determining that the lock does not exist, creating (506), by a creating module (214), a new lock for the requested resource; storing (508), by the creating module (214), details of the new lock in the memory; acquiring (510), by an acquiring module (216), the new lock for a predefined time period; and periodically updating (512), by an updating module (220), a status of the acquired new lock in the memory.

2. The method (500) as claimed in claim 1, wherein the at least one operation comprises one of a create operation, a modify operation, and a delete operation on the requested resource.

3. The method (500) as claimed in claim 2, comprises: upon performing the at least one operation on the requested resource, receiving, by the receiving module (210), an unlock request corresponding to the acquired new lock from at least one application platform; andreleasing, by a releasing module (218), the acquired new lock from the requested resource in response to receiving the unlock request.

4. The method (500) as claimed in claim 1, comprises: detecting, by the determining module (212), a failure to create the new lock in the memory; upon detecting the failure, retrying, by the creating module (214), the creation of the new lock for a predefined number of attempts; and upon unsuccessful creation of the new lock after the predefined number of attempts, releasing, by the releasing module (218), the lock for the requested resource that already exists in the memory.

5. The method (500) as claimed in claim 1, wherein the details of the created lock comprise a unique identifier (ID) associated with the requested resource and an expiration time for the created new lock.

6. The method (500) as claimed in claim 1, wherein the resource comprises at least one of: a record, a file, a configuration, or a data entity.

7. The method (500) as claimed in claim 1, wherein the memory is a cache memory located in the distributed network environment.

8. The method (500) as claimed in claim 1, wherein the status comprises one of an available status of the new lock and an unavailable status of the new lock.

9. The method (500) as claimed in claim 1, comprises: upon receiving the request, maintaining, by the updating module (220), a counter for each request received for creating the new lock, each unlock request for releasing the new lock, each successful acquisition of the new lock for the requestedresource, successful lock updates in the memory, successful lock release and successful record deletion from the memory.

10. A system (108) for implementing a lock management system in a distributed network environment, the system (108) comprising: a receiving module (210) configured to receive a request from a network node associated with the distributed network environment to create a lock for a resource on which at least one operation is to be performed; a determining module (212) configured to determine whether the lock for the requested resource already exists in a memory of the distributed network environment; a creating module (214) configured to: create a new lock for the requested resource, upon determining that the lock does not exist; and store details of the new lock in the memory; an acquiring module (216) configured to acquire the new lock for a predefined time period; and an updating module (220) configured to periodically update a status of the acquired new lock in the memory.

11. The system (108) as claimed in claim 10, wherein the at least one operation comprises one of a create operation, a modify operation, and a delete operation on the requested resource.

12. The system (108) as claimed in claim 11, wherein, upon performing the at least one operation on the requested resource, the receiving module (210) is configured to receive an unlock request corresponding to the acquired new lock from at least one application platform; anda releasing module (218) configured to release the acquired new lock from the requested resource in response to receiving the unlock request.

13. The system (108) as claimed in claim 10, wherein, the determining module (212) is configured to detect a failure to create the new lock in the memory; upon detecting the failure, the creating module (214) is configured to retry the creation of the new lock for a predefined number of attempts; and the releasing module (218) further configured to release the existing lock for the requested resource that already exists in the memory, upon unsuccessful creation of the new lock after the predefined number of attempts.

14. The system (108) as claimed in claim 10, wherein the details of the created lock comprise a unique identifier (ID) associated with the requested resource and an expiration time for the created new lock.

15. The system (108) as claimed in claim 10, wherein the resource comprises at least one of: a record, a file, a configuration, or a data entity.

16. The system (108) as claimed in claim 10, wherein the memory is a cache memory located in the distributed network environment.

17. The system (108) as claimed in claim 10, wherein the status comprises one of an available status of the new lock and an unavailable status of the new lock.

18. The system (108) as claimed in claim 10, wherein, the updating module (220) is configured to maintain a counter for each request received for creating the new lock, each unlock request for releasing the new lock, each successful acquisition of the new lock for the requested resource, successful lockupdates in the memory, successful lock release and successful record deletion from the memory.

19. A computer program product comprising a non-transitory computer- readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform a method (500) for implementing a locking management system in a distributed network environment, the method (500) comprising: receiving, by a receiving module (210), a request from a network node associated with the distributed network environment to create a lock for a resource on which at least one operation is to be performed; determining, by a determining module (212), whether the lock for the requested resource already exists in a memory of the distributed network environment; upon determining that the lock does not exist, creating, by a creating module (214), a new lock for the requested resource; storing, by the creating module (214), details of the new lock in the memory; acquiring, by an acquiring module (216), the new lock for a predefined time period; and periodically updating, by an updating module (220), a status of the acquired new lock in the memory.

Images