阅读说明：本技术 管理对外部资源的锁租赁 (managing lock leases to external resources ) 是由 K·G·S·巴拉蒂 A·鲍布达拉赫 D·尼斯莫弗 于 2018-04-07 设计创作，主要内容包括：根据示例,一种装置可以包括处理器和其上存储有将使得处理器执行以下操作的机器可读指令的存储器：将外部资源的副本存储在该装置上,传输对针对外部资源的锁租赁的针对续订的请求,以及基于未能接收到对续订请求的应答,使该装置进入以下状态：处理器处理对外部资源的所存储的副本的新的操作,并且在锁租赁丢失的确定之后,处理器输出该装置丢失锁租赁的通知。(according to an example, an apparatus may include a processor and a memory having stored thereon machine readable instructions that will cause the processor to: storing a copy of the external resource on the apparatus, transmitting a request for renewal for a lock lease for the external resource, and upon failing to receive a reply to the renewal request, causing the apparatus to enter the following states: the processor processes a new operation on the stored copy of the external resource and, after a determination that the lock lease is lost, the processor outputs a notification that the device lost the lock lease.)

1. An apparatus, comprising:

A processor; and

A memory having stored thereon machine-readable instructions that will cause the processor to:

Storing a copy of an external resource on the device;

Transmitting a request for renewal for lock lease to the external resource; and

upon failing to receive a reply to the renewal request, causing the apparatus to enter a state in which:

The processor processing a new operation on the stored copy of the external resource; and

After the determination that the lock lease is lost, the processor outputs a notification that the device lost the lock lease.

2. The apparatus of claim 1, further comprising:

Machine readable instructions that will cause the processor to:

Requesting additional lock lease renewal for the external resource until:

Expiration of a timer or counter; or

The lock lease is renewed.

3. The apparatus of claim 1, further comprising:

machine readable instructions that will cause the processor to:

requesting version information of the external resource from a server based on the lock lease being available;

outputting an instruction to save the copy of the external resource as a new resource on the server based on a determination that an updated version of the external resource is available on the server according to the version information.

4. The apparatus of claim 3, further comprising:

machine readable instructions that will cause the processor to:

Outputting, based on a determination that an updated version of the external resource is available on the server in accordance with the version information, an instruction to overwrite the updated version of the external resource on the server with a current version of the copy of the external resource stored on the apparatus.

5. the apparatus of claim 1, wherein to determine that the apparatus lost the lock lease, the machine readable instructions are to cause the processor to receive an indication that the lock lease is not available.

6. The apparatus of claim 1, wherein to determine that the apparatus lost the lock lease, the machine-readable instructions are to cause the processor to:

determining that an updated version of the external resource is available outside of the apparatus; and

Outputting a notification indicating that the updated version of the external resource is available.

7. the apparatus of claim 1, wherein the failure to receive the reply to the renewal request is due to a loss of a network connection of the apparatus, the apparatus further comprising:

machine readable instructions that will cause the processor to perform at least one of:

Requesting renewal of the lock lease after reestablishment of the network connection; or

based on a determination that a version of the external resource external to the apparatus does not change from a version of the copy of the external resource stored on the apparatus, performing one of:

Requesting renewal of the lock lease; or

requesting override to reacquire the lock lease.

8. a computer-implemented method, comprising:

Storing, by a processor, a copy of an external resource on a device;

Transmitting, by the processor, a request for renewal for lock lease for the external resource;

entering, by the processor, the apparatus into a state based on the processor failing to receive a reply to the renewal request, wherein:

The processor processing a new operation on the stored copy of the external resource; and

After the determination that the lock lease is lost, the processor outputs a notification that the device lost the lock lease.

9. The method of claim 8, further comprising:

Requesting additional lock lease renewal for the external resource;

determining that a timer or counter has expired; or

determining that the lock lease is renewed.

10. The method of claim 8, further comprising:

requesting, from a server, version information for the external resource based on the determination that the lock lease is available; and

Determining that an updated version of the external resource is available on the server according to the version information.

11. the method of claim 10, further comprising:

based on a determination that an updated version of the external resource is available, performing at least one of:

outputting instructions to save the copy of the external resource on the device as a new resource on the server; or

outputting instructions to overwrite the updated version of the external resource on the server with a current version of the copy of the external resource stored on the device.

12. The method of claim 8, further comprising:

receiving an indication that an updated version of the external resource is available outside of the apparatus; and

outputting a notification indicating that the updated version of the external resource is available.

13. A non-transitory computer readable medium having stored thereon machine readable instructions which, when executed by a processor, cause the processor to:

storing a copy of the external resource on the device;

Transmitting a request for renewal for lock lease to the external resource;

Based on failing to receive a reply to the renewal request, causing the apparatus to enter a state in which:

the processor processing a new operation on the stored copy of the external resource; and

after the determination that the lock lease is lost, the processor outputs a notification that the device lost the lock lease.

14. The non-transitory computer readable medium of claim 13, wherein the instructions are to cause the processor to:

requesting additional lock lease renewal for the external resource until:

Expiration of a timer or counter; or

The lock lease is renewed.

15. The non-transitory computer readable medium of claim 13, wherein the instructions are to cause the processor to:

Requesting version information of the external resource from a server based on the determination that the lock lease is renewed; and

Determining that an updated version of the external resource is available on the server according to the version information;

Based on a determination that an updated version of the external resource is available on the server, performing at least one of:

Outputting instructions to save the copy of the external resource on the device as a new resource on the server; or

Outputting instructions to overwrite the updated version of the external resource on the server with a current version of the copy of the external resource stored on the device.

background

In a client server environment, multiple clients typically cooperate with each other in creating and editing network resources (such as files, applications, data, etc.) owned and managed by the server. Clients typically store or cache data related to network resources locally, where the clients make changes to the locally stored or cached data. Accessing and modifying data locally is more efficient and relieves the server of the burden so that the server can handle more requests. Local access to data can also generally improve response time of network resources, such as applications, because the network resources do not need to wait for a client to send data to a server over a network at each request.

Drawings

Features of the present disclosure are illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:

FIG. 1 depicts a block diagram of a network environment in which various features of an apparatus, such as a client machine, may be implemented in accordance with an embodiment of the present disclosure;

FIG. 2 shows a diagram of a device state machine according to an embodiment of the present disclosure;

FIG. 3 illustrates a process flow diagram for managing lock leases to an external resource in accordance with an embodiment of the present disclosure;

FIG. 4 shows a flow diagram of a method for managing lock leases for external resources, in accordance with an embodiment of the present disclosure; and

FIG. 5 illustrates a flow diagram of a method for managing renewal of lock leases for external resources on a server in accordance with an embodiment of the present disclosure.

Detailed Description

For simplicity and illustrative purposes, the present disclosure is described by referring mainly to the embodiments. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. It should be apparent, however, that the present disclosure may be practiced without limitation to these specific details. In other instances, some methods and structures have not been described in detail so as not to unnecessarily obscure the present disclosure.

Throughout this disclosure, the terms "a" and "an" are intended to mean at least one particular element. As used herein, the term "including" means including but not limited to. The term "based on" means based at least in part on.

One consideration in providing cooperative access to external resources (equivalently, network resources) is ensuring that multiple client machines do not perform conflicting actions on the external resources. For example, two clients may update a locally stored version of an external resource before saving it at the server, and thus, a conflict may occur when saving a version of an external resource at the server. One mechanism for preventing this type of conflict between multiple clients is to grant lock leases to an external resource to one client at a time, where the client with the granted lock lease is granted exclusive editorial control over the external resource. Lock leases are typically time-limited leases of locks to external resources. That is, the lock lease typically has an expiration time after the lock lease granted to the client, and the client will lose the lock lease if the client does not renew the lock lease before the expiration time.

disclosed herein are apparatuses and methods that can minimize the possibility of conflicts when multiple users are processing or editing the same external resource. External resources may be defined as files, applications, data, etc. owned and managed by the server. In a particular example, the external resource may be available from Microsoft Corporation^TMacquired PowerApps^TMapplication is carried out. The server may make external resources available for creation and editing by multiple users on multiple client machines connected to the server via one or more networks. In addition, external resources may not support coauthoring, and thus, each user may be in phaseA copy of the external resource is stored or cached on the respective client machine to edit the external resource at any given time. Processing copies of the external resource stored or cached on the client machine may make editing of the external resource more efficient and may reduce the burden on the server than when such editing is performed on the external resource at the server.

The methods and apparatus disclosed herein may minimize the likelihood of conflicts by granting exclusive editing control of an external resource to one of the client machines at a time. The lock lease may be a time-limited lock lease and thus may expire after a predefined time period, which may be defined in minutes, hours, days, etc. The client machine may have an opportunity to maintain ownership of the lock lease by renewing the lock lease before the expiration of the predefined time period. To ensure that the client machine does not inadvertently lose the lock lease, the client machine may set a task (such as a background task) to automatically renew the lock lease at some periodic interval before the lock lease expires.

It may occur that the lock lease is not automatically renewed at periodic intervals. For example, if the network connection between the client machine and the server is unstable, e.g., has failed, has been interrupted, etc., the lock lease may not be renewed. Lock leases may not be renewed in time if the client machine fails, such as a cable pull, a network interface failure, a virus on the client machine, etc. According to embodiments, in the methods and apparatus disclosed herein, a client machine may maintain lock leases under unstable network conditions and with reduced user intervention requirements.

Client machines are traditionally represented in one of two states: "acquired" and "not acquired". The client machine in the "acquired" state is the client machine that has acquired the lock lease, while all other client machines are in the "not acquired" state. A client machine in the "acquired" state may remain in that state as long as the client machine can prove that the client machine is the only owner of the lock lease, e.g., by renewing the lock lease before the lock lease period expires. If the client machine does not renew the lock lease before the lock lease expires, the client machine may lose the lock lease and may submit another request to acquire the lock lease. As described using the following example, restricting the client machine to these two states may result in unnecessary "noise":

1) The client machine acquires the exclusive lock lease and enters the "acquired" state.

2) The client machine cannot renew the lock (e.g., due to network instability) and the lock lease is lost. The client machine is now in the "not acquired" state.

3) The network connection is re-established and the client machine can reacquire the lock lease.

in some systems, events (2) and (3) may result in a dialog box being shown to the user of the client machine, where the dialog box shows information and may request input of instructions on how to proceed. Additionally, in the above example, there may not be any other client machines attempting to acquire a mutually exclusive lock between events (2) and (3). Thus, in this example, the dialog boxes shown to the user may not be needed, but they are shown because the client machine is uncertain whether another client machine has acquired the lock lease (e.g., due to network instability in this example). As such, a technical problem associated with conventional approaches for managing lock leases for network resources may be that dialogs or notifications may be unnecessarily output to a user, which may unnecessarily consume system resources of the client machine.

According to embodiments disclosed herein, a client machine may enter a particular state when the client machine is not certain whether a lock lease to an external resource will be renewed. This particular state may be referred to as a "previously acquired but currently unknown" state. In this state, the client machine may operate under the optimistic assumption that the client machine will be able to reacquire the lost lock lease. That is, for example, when the client machine is uncertain whether a lock lease has been renewed, the client machine may not automatically output a notification to the user that a lock lease has been lost. Rather, when the client machine determines that the lock lease has been lost, the client machine may output a notification, which may occur after communication between the client machine and the server is restored.

by implementing the methods and apparatus disclosed herein, the number of notifications output to the user when the customer machine cannot renew the lock lease can be reduced or minimized. Thus, a technical solution to the above technical problem may be that the utilization of system resources of a client machine may be reduced, since the system resources, such as a processor, in the client machine may output a smaller number of notifications. Additionally, by implementing the methods and apparatus disclosed herein, a notification containing relevant information for the user may be output, which may assist the user in making a decision as to whether to: abandoning their changes to the locally stored copy of the external resource, using other names to save the locally stored copy of the external resource, or using the locally stored copy of the external resource to enforce overrides of the latest version of the external resource.

Fig. 1 depicts a block diagram of a network environment 100 in which various features of an apparatus, e.g., a client machine, may be implemented in accordance with an embodiment of the present disclosure. The network environment 100 may include a device 102 in communication with a server 104 via a network 106. The network 106 may be a local area network, a wide area network, the internet, etc. Although a single device 102 has been depicted in fig. 1, it should be understood that multiple devices having similar or different configurations with respect to the device 102 may be included in the network environment 100. Additionally, although a single server 104 is depicted in FIG. 1, it should be understood that multiple servers having similar or different configurations with respect to server 104 may be included in network environment 100.

the device 102 may be a client machine such as a personal computer, laptop computer, tablet computer, smart phone, and the like. Additionally, the apparatus 102 may include a processor 110 that may communicate with the server 104 via an interface 112. The processor 110 may be a semiconductor-based microprocessor, Central Processing Unit (CPU), Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA), and/or other hardware device. The interface 112 may include hardware, software, or a combination thereof to facilitate communication of information with the server 104. Although the apparatus 102 is depicted as having a single processor 110, it should be understood that the apparatus 102 may include additional processors 110 without departing from the scope of the apparatus 102.

The apparatus 102 may also include a data repository 114, an output device 116, and a memory 118. The data store 114 may be a non-transitory computer readable medium comprising electronic, magnetic, optical, or other types of physical storage devices. The output device 116 may be a speaker, display, printer, etc., on or through which the processor 110 may output notifications to a user. The memory 118 may be, for example, Random Access Memory (RAM), Electrically Erasable Programmable Read Only Memory (EEPROM), a memory device, an optical disk, and so forth. The memory 118, which may also be referred to as a computer-readable storage medium, may be a non-transitory machine-readable storage medium, where the term "non-transitory" does not include a transitory propagating signal. In any event, the memory 118 may store thereon the machine-readable instructions 120 and 126. The data store 114 may be similar to any of the devices listed above with respect to the memory 118. Additionally, or in other examples, data store 114 and memory 118 may be the same device.

the processor 110 may fetch, decode, and execute the instructions 120 to store a copy 132 of the external resource 140 on the device 102. As shown, external resources 140 may be stored on server 104 and may be network resources, such as files, applications, data, and the like. As a particular example, external resource 140 may be Microsoft Powerapps^TMApplication is carried out. The server 104 may own and manage the external resources 140 and may make the external resources 140 available for creation and editing by multiple users on multiple devices (e.g., client machines). The processor 110 may download and store the copy 132 of the external resource 140 in the data store 114 of the device 102 such that the processor 110 may effect user-controlled actions, such as accessing, modifying, renewing, etc., the copy 132 of the external resource 140. By acting on the copy 132 of the external resource 140 stored on the device 102, as discussed herein, rather than actingThe response time associated with acting on the external resource may be reduced compared to the response time associated with acting on the external resource 140 stored on the server 104 for the external resource 140 stored on the server 104.

processor 110 may acquire, decode, and execute instructions 122 to acquire lock lease 134 of external resource 140. Processor 110 may store in data store 114 an indication of lock lease 134 or lock lease 134 that device 102 has acquired external resource 140. Lock lease 134 may grant exclusive editorial control of external resource 140 to device 102 for a period of time. In particular, for example, lock lease 134 may be a contract between device 102 (a client) and server 104, where server 104 grants device 102 exclusive editorial control of external resource 140 over a period of time. The server 104 may adhere to the contract until the time period expires and/or may expand the contract in response to receiving an expansion request from the apparatus 102. In other words, while device 102 has been granted lock lease 134, server 104 may ignore requests from other devices (e.g., client machines) for exclusive editing control of external resource 140 and/or may prevent other devices from being granted lock leases to external resource 140.

Once granted to the apparatus 102, the lock lease 134 for the external resource 140 may be active for a predefined period of time, which may be user-defined, defined by an administrator of the server 104, and so on. Before the expiration of the predefined time period, processor 110 may fetch, decode, and execute instructions 124 to transmit a renewal request for lock lease 134. For example, processor 110 may set a task (e.g., a background task) to periodically transmit a renewal request for lock lease 134 before a predefined time period expires at which lock lease 134 expires.

under normal circumstances, for example, when device 102 and server 104 are operating normally and the connection to network 106 is operating normally, server 104 may receive a renewal request for lock lease 134. Additionally, server 104 may send a reply to device 102 indicating that lock lease 134 has been renewed or indicating that lock lease 134 has not been renewed. However, when there is an error, such as a network 106 outage, network outage, or other error, server 104 may not receive a renewal request for lock lease 134 and/or device 102 may not receive a reply from server 106. Based on failing to receive a reply to the renewal request, the processor 110 may fetch, decode, and execute the instructions 126 to enter a particular state in which the processor 110 handles new operations on the stored copy 132 of the external resource 140. The new operation may be an operation that the user may initiate and the processor 110 may perform after the device 102 enters a particular state. Additionally, while in a particular state, the processor 110 may also process existing operations, e.g., operations that the processor 110 is already processing and/or in a queue to be processed before the device 102 enters the particular state. Further, while in the particular state and after determining that the lock lease is lost, processor 110 may output a notification that device 102 lost lock lease 134.

That is, for example, processor 110 may determine that within a certain amount of time from the transmission of the renewal request for lock lease 134 from processor 110, processor 110 has not received a reply to the renewal request from server 104. The particular amount of time may be an amount of time corresponding to a normal amount of time that passes between normal communications between the device 102 and the server 104. The particular amount of time may additionally or alternatively correspond to a user-defined period of time. Regardless, instead of automatically outputting a notification that device 102 has lost lock lease 134, processor 110 may enter a state discussed herein, such as an optimistic state, in which processor 110 operates under the assumption that device 102 will reacquire lock lease 134.

As discussed herein, while in the optimistic state, the processor 110 may continue to process existing operations and new operations on the stored copy 132 of the external resource 140. For example, the processor 110 may continue to process operations such as existing edit commands and new edit commands to the stored copy 132 of the external resource 140. Further, processor 110 may remain in an optimistic state until processor 110 determines that device 102 has lost lock lease 134. In response to receiving an acknowledgement from server 104 that device 102 has lost lock lease 134, processor 110 may determine that device 102 has lost lock lease 134. For example, when device 102 cannot communicate with server 104, server 104 may revoke lock lease 134. For example, server 104 may revoke lock lease 134 because the period of time lock lease 134 remains valid may have expired before server 104 receives a renewal request for lock lease 134. Based on determining that device 102 has lost lock lease 134, processor 110 may output a notification that device 102 has lost lock lease 134.

As mentioned above, the output device 116 may be a speaker, display, printer, or the like. Thus, for example, processor 110 may output a notification that device 102 has lost lock lease 134 as a visual and/or audible notification. By executing instructions 122-126, processor 110 may delay the output of the notification until processor 110 determines that device 102 has lost lock lease 134. On the one hand, by delaying the output of the notification in this manner, processor 110 may output a relatively small number of notifications because processor 110 may not output a notification in the event that device 102 acquires or reacquires lock lease 134 after previously failing to receive a reply from server 104.

referring now to FIG. 2, a depiction of a device state machine 200 is shown, in accordance with one embodiment. The description of fig. 2 is made with reference to the elements depicted in fig. 1. In particular, FIG. 2 depicts various states of the device 102 with respect to lock leases 134 of external resources 140. As shown in FIG. 2, device 102 may be in an initial state 202, e.g., an "unacquired" state, in which device 102 does not have lock leases 134 for external resources 140. After transmitting a request for lock lease 134 to server 104, device 102 may acquire lock lease 134 as indicated by arrow 204. In other words, the apparatus 102 may acquire a distributed exclusive lock of the external resource 140, and thus may be in the "acquired" state 206. As a particular example, when a user provides input to the apparatus 102 to open a particular application for editing, the apparatus 102 may acquire an exclusive lock, such as lock lease 134. Device 102 may acquire lock lease 134 within a set period of time, which may be known to both the distributed lock service (e.g., server 104) and device 102. Once lock lease 134 is acquired, device 102 may download and store a copy 132 of external resource 140 locally, for example, in data store 114.

As indicated by arrow 208, processor 110 may run a task, such as a background task, that periodically attempts to renew lock lease 134 before lock lease 134 expires. The processor 110 may continue to run the task 208 as long as the renewal is successful and the user is still editing the copy 132 of the external resource 140.

Due to network instability and other potential problems, processor 110 may not be able to renew lock lease 134 before the set time period for which lock lease 134 is valid expires. Additionally, as indicated by arrow 210, processor 110 may determine that lock lease 134 has expired based on the clock of device 102 and the known duration of the most recent lock lease 134. In this case, the device 102 may enter a "previously acquired but currently unknown" state 212. In this state, processor 110 may not know whether lock lease 134 is available, or whether server 104 has granted another client machine a lock lease to external resource 140. Based on processor 110 transmitting a renewal request for lock lease 134, processor 110 failing to receive a reply to the request within a certain period of time, or lock lease 134 expiring, device 102 may enter a "previously acquired but currently unknown" state 212.

While in the "previously acquired but currently unknown" state 212, processor 110 may continue to run background tasks to reacquire lock lease 134. In this way, processor 110 may successfully reacquire lock lease 134 when the network connection to server 104 is again available, as indicated by arrow 214. Additionally, once the user has completed editing the copy 132 of the external resource 140 and saved the edits, the device 102 may release the lock lease 134 as indicated by arrow 216 so that other devices or devices 102 may acquire the lock lease 134 in the future. In this case, no user intervention may be required or required during network instability that occurs between the operations indicated by arrows 210 and 214.

According to an example of the present disclosure, a user may be allowed to edit and continue editing the copy 132 of the external resource 140 on the device 102 while the device 102 is in the "acquired" state 206 or in the "previously acquired but currently unknown" state 212. However, attempts may be allowed to save the copy 132 of the external resource 140 on the server 104 when the device 102 is in the "acquired" state 206, but may not be allowed when the device 102 is in the "previously acquired but currently unknown" state 212.

While in the "previously acquired but currently unknown" state 212, and after the network connection to the server 104 is again available, the user may be provided with the option of saving the copy 132 of the external resource 140 on the server 104 using another filename. In this regard, the user may be provided with the option to perform a "save as" operation on the copy 132 of the external resource 140 on the server 104. A conflict may be detected while the copy 132 is saved on the server 140 (e.g., other users may have saved an updated version of the external resource 140 while the device 102 is in the "previously acquired but currently unknown" state 212). In this case, the user may be provided with the option to override the other user's changes, "save as" other names, or discard the current user change.

Upon transition 210 from the acquired state 206 to a previously acquired but currently unknown state 212, an information message may be output to the user (e.g., via the output device 116) indicating that the user is allowed to continue editing 132 the copy, but that a save operation to the server 104 may not be available before the apparatus 102 returns to the acquired state 206. Further, upon transition 214 from the "previously acquired but currently unknown" state 212 to the "acquired" state 206, an information message may be output to the user (e.g., via the output device 116) indicating that the save to the server 104 may be assured of being in a valid state.

While in "previously acquired but currently unknown" state 212, and after the network connection to server 104 is again available, processor 110 may receive an acknowledgement from server 104 indicating that device 102 has lost lock lease 134 to external resource 140. That is, for example, server 104 may send an acknowledgement to device 102 indicating that device 102 has lost lock lease 134 and that lock lease 134 is still available. Alternatively, the reply may indicate that device 102 has lost lock lease 134 and that another client machine has acquired lock lease 134. In either of these cases, device 102 may enter an "unacquired" state 202, e.g., a state in which device 102 does not have a lock lease 134 to external resource 140.

Before and/or during the transition 218 from the "previously acquired but currently unknown" state 212 to the "not acquired" state 202, the processor 110 may display a prompt dialog box via the output device 116 to notify the user of the transition from the "previously acquired but currently unknown" state 212 to the "not acquired" state 218. The prompt dialog may indicate that another user has ownership of external resource 140, e.g., that another user has acquired a lock lease to external resource 140. The prompt dialog may also indicate that continued editing of the copy 132 of the external resource 140 is no longer recommended. Additionally, the prompt dialog may provide the user with the option of storing the copy 132 as another file on the server 104 or continuing to risk itself, in which case the user may not want other users to save their changes to the external resource 140.

Referring now to FIG. 3, a process flow diagram 300 is shown for managing lock leases 134 to an external resource 140, according to one embodiment. The description of fig. 3 is made with reference to the elements depicted in fig. 1. Initially, a user (UserA) may not currently have a lock lease 134 to an external resource 140, as shown in block 302. Further, the user may attempt to open the external resource 140 on the user's client machine (e.g., device 102), e.g., attempt to open an application. This may result in processor 110 of device 102 attempting to acquire lock lease 134 for external resource 140 from server 104. If the attempt is successful, device 102 may acquire lock lease 134 to external resource 140, as indicated by arrow 304 and block 306, and the user may have exclusive editing access to external resource 140. Further, the copy 132 of the external resource 140 may be stored locally on the device 102, as discussed herein.

Processor 110 may schedule a task to renew lock lease 134 before lock lease 134 expires. Additionally, as shown at block 306, processor 110 may successfully renew lock lease 134, as indicated by arrow 308, to continue with a valid lock lease 134 for external resource 140, as shown at block 306. Processor 110 may continue to attempt to renew lock lease 134 periodically, for example, before lock lease 134 expires.

however, if the renewal attempt is unsuccessful, e.g., due to a connection problem (the user is offline), an interruption to network 106, etc., processor 110 may retry the renewal attempt. During or after the renewal attempt, processor 110 may determine that lock lease 134 has expired at block 312. After determining that lock lease 134 has expired, processor 110 may continue to attempt to renew lock lease 134, as indicated by arrow 314. The processor 110 may continue to make renewal attempts until the processor 110 determines that one of a plurality of conditions has been reached. For example, processor 110 may determine that the attempt to renew lock lease 134 is successful, as indicated by arrow 316. In this case, device 102 may have reacquired lock lease 134, as shown at block 306, and processor 110 may continue to renew the attempt as described above.

If the renewal attempt 314 fails, for example, because another user (UserB) acquired a lock lease to the external resource 140 while the user (UserA) was offline or disconnected from the server 104, the UserA may be notified that others are actively editing the external resource 140, as indicated by arrow 318. In other words, as shown at block 320, processor 110 may determine that another client machine has a lock lease to external resource 140. Additionally, the processor 110 may notify the UserA that the user may decide to reserve or abandon a session with the copy 132 of the external resource 140.

processor 110 may also schedule periodic tasks at regular intervals (e.g., every 5 minutes, every 10 minutes, etc.) to retry acquiring lock lease 134 for external resource 140. Additionally, processor 110 may attempt to acquire lock lease 134 at regular intervals, as indicated by arrow 322, until device 102 is able to acquire an exclusive lock lease 134 for external resource 140 (e.g., another user does not have a valid lock lease for external resource 140). If the retry is successful, the device 102 (e.g., UserA) may reacquire the exclusive lock lease 134 to the external resource 140 as indicated by arrow 324.

As part of or in addition to the renewal attempt at 314 or 322, the processor 110 may perform a version check as indicated by arrow 326. The processor 110 may perform a version check to determine whether the copy 132 of the external resource 140 on the device 102 on which the user is still operating is the most recent version of the external resource 140. If the version check fails, indicating that another user has changed an external resource 140 on the server 104 while the device 102 is offline or disconnected from the server 104, the processor 110 may output a message indicating that the versions do not match. That is, the processor 110 may determine that the external resource has been changed, as shown in block 328. Further, the processor 110 may prompt the user to forgo the user's changes to the copy 132 of the external resource 140 or to force the override of the external resource 140 on the server 104. Processor 110 may receive a user instruction to force the version of copy 132 on device 102 to overwrite the version of external resource 140, and device 102 may acquire lock lease 134 again, as indicated by arrow 330. Processor 110 may instead receive a user instruction to relinquish the user's changes made to copy 132 of external resource 140, in which case device 102 may not drop lock lease 134, and may return to block 302.

if device 102 reacquires lock lease 134 and returns to block 306, processor 110 may continue to attempt to renew lock lease 134 until the user completes editing copy 132 of external resource 140. If the user has finished editing the copy 132 and has uploaded or overwritten an updated version of the external resource 140 on the server 104, the processor 110 may discard the lock lease 134 as indicated by arrow 332. Accordingly, device 102 may return to block 302, where device 102 does not have lock lease 134. Further, in the event that lock lease 134 is covered, for example, when server 104 along with apparatus 102 revokes lock lease 134 and grants the lock lease to another client machine, apparatus 102 may return to block 302.

Turning now to FIG. 4, a flow diagram is shown of a method 400 for managing lock leases 134 of external resources 140, according to one embodiment. It should be apparent to those of ordinary skill in the art that the method 400 may represent a general illustration, and that other operations may be added or existing operations may be deleted, modified or rearranged without departing from the scope of the method 400. For purposes of illustration, the description of the method 400 is made with reference to the device 102 and the server 104 shown in fig. 1. It should be understood that devices having other configurations may be implemented to perform the method 400 without departing from the scope of the method 400.

at block 402, the processor 110 may execute the instructions 120 to store the copy 132 of the external resource 140 on the device 102. External resources 140 may be stored and/or hosted on server 104. Further, in response to receiving a user instruction to store and/or execute the external resource 140, the processor 110 may first access the external resource 140 via the network 106. Before, during, or after storing the copy 132 of the external resource 140 on the apparatus 102 (e.g., in the data store 114 of the apparatus 102), the server 104 may grant an exclusive lock, such as lock lease 134, to the apparatus 110 on the external resource 140. Processor 110 may request lock lease 134 by attempting to download a copy of external resource 140 from server 104. If another client machine is not currently acquiring a lock lease to external resource 140, server 104 may grant the lock lease. In any event, lock lease 134 may be set to expire after a predefined time period, which may be known to both processor 110 and server 104, and may begin once processor 110 has acquired the lock lease.

At block 404, processor 110 may execute instructions 124 to transmit a renewal request for lock lease 134 of external resource 140. As discussed herein, processor 110 may transmit a renewal request for lock lease 134 before lock lease 134 expires. The processor 110 may transmit a renewal request to the server 104 that stores and/or hosts the external resource 140. In response to receiving the reply granting renewal, processor 110 may reset a timer or counter so that processor 110 may transmit another renewal request before the expiration of the current lock lease 134. According to an example, processor 110 may proceed to set a background task to periodically renew lock lease 134 before expiration of a predefined time period.

at block 406, the processor 110 may execute the instructions 126 to cause the device 102 to enter a particular state based on failing to receive a reply to the renewal request. In this particular state, the processor 110 may process a new operation on the stored copy 132 of the external resource 140. Further, the processor 110 may process existing operations, e.g., operations that the processor 110 is already processing and/or in a processing queue before the device 100 enters a particular state. In this regard, the processor 110 may continue to implement the user instructions to edit the copy 132 of the external resource 140 in a particular state. Additionally, in a particular state, after determining that lock lease 134 is lost, processor 110 may output a notification that device 102 has lost lock lease 134. In one aspect, processor 110 may not output the notification until processor 110 determines that lock lease 134 is lost. As discussed herein, by delaying the output of the notification, processor 110 may operate under the optimistic belief that lock lease 134 may be reacquired.

Referring now to FIG. 5, a flow diagram is shown of a method 500 for managing renewal of lock leases 134 of external resources 140 on server 104, according to one embodiment. The processor 110 may perform the method 500 during or after performance of the method 400 depicted in fig. 4. Thus, for example, processor 110 may perform method 500 after acquiring lock lease 134 for external resource 140 and while processor 110 is in the particular state discussed above with respect to block 406. For purposes of illustration, a description of the method 500 is made with reference to the network environment 102 shown in FIG. 1 and the process flow diagram 300 shown in FIG. 3.

At block 502, processor 110 may determine that a time period has been reached to renew lock lease 134 of external resource 140. The time period to renew lock lease 134 may be set to be reached before the time period for lock lease 134 expires. As an example, a time period for renewal lock lease 134 may be set to provide processor 110 with sufficient time to submit a renewal request and approve the renewal request before lock lease 134 expires.

At block 504, processor 110 may send a lock lease renewal request to server 104, which controls the allocation of lock leases 134 among multiple client machines. At block 506, processor 110 may determine whether a response to the lock lease renewal request has been received from server 104. For example, the processor 110 may not receive a response from the server 104 when there is a network error or interruption. Based on determining that no response to the lock lease renewal request has been received, processor 110 may increment a counter and/or timer, as shown at block 508. Further, at block 510, processor 110 may determine whether the counter and/or the timer has expired since processor 110 sent the lock lease renewal request, e.g., reached a predetermined count or a predetermined time.

Based on determining that the counter and/or timer has not expired at block 510, processor 110 may send another lock lease renewal request at block 504. The processor 110 may repeat block 504-510 as long as the processor 110 continues to fail to receive a response from the server 104 at block 506 and the counter and/or timer has not expired at block 510. However, based on determining that the counter and/or timer has expired at block 510, the processor 110 may output an indication that the counter and/or timer has expired without receiving a response from the server 104 at block 512. The processor 110 may output a notification via the output device 116 so that the user can determine the reason for failing to receive a response from the server 104. Further, the method 500 may end as indicated at block 514.

After block 514, processor 110 may continue to send a lock lease renewal request to server 104, as discussed above with respect to fig. 3. That is, for example, since lock lease 134 may have expired after block 514, after processor 110 receives the response from server 104, processor 110 may determine that lock lease 134 is available and that external resource 140 has not changed. In this case, device 102 may reacquire the lock lease as indicated by arrow 316. In another example, processor 110 may determine that another client machine has acquired the lock lease (block 320), and processor 110 may force server 104 to drop the lock lease to the other client and provide lock lease 134 to apparatus 102, as illustrated by arrow 324. In another example, processor 110 may determine that another client has changed an external resource (block 328). In this example, processor 110 may force overriding of the changed external resource and may reacquire lock lease 134 of external resource 140.

referring again to fig. 5, at block 506, based on determining that a response was received from server 104, processor 110 may determine whether processor 110 received a response from server 104 before or after expiration of the lock lease 134 time period. In the event processor 110 receives a response from server 104 before expiration of lock lease 134 time period, processor 110 may determine at block 518 that lock lease 134 has been renewed. Further, after block 518, processor 110 may repeat method 500 beginning at block 502.

However, in the event processor 110 receives a response after expiration of lock lease 134 time period, processor 110 may determine whether lock lease 134 is available at block 520. Based on determining that lock lease 134 is not available, processor 110 may output a notification that another user (or equivalently, another client machine) has acquired a lock lease of external resource 140. The processor 110 may output the notification via the output device 116. In some examples, method 500 may end after block 522. In other examples, processor 110 may continue to send the lock lease renewal request to server 104, as discussed above with respect to fig. 3.

based on determining that a lock lease for external resource 140 is available, at block 524, processor 110 may request version information for external resource 140 from server 104 and may determine whether an updated version (e.g., a newer version) of external resource 140 has been saved at server 104. Based on determining that the updated version of external resource 140 has not been saved to server 104, processor 110 may reacquire lock lease 134, as shown in block 526. Additionally, after block 526, processor 110 may repeat method 500 beginning at block 502.

However, based on determining that the updated version of the external resource 140 has been saved to the server 140, the processor 110 may output a notification that the updated version of the external resource 140 was saved at the server 104. The processor 110 may output the notification via the output device 116. In this regard, the processor 110 may notify the user of the device 102 that the copy 132 of the external resource 140 stored in the data store 114 may not be the most recent version of the external resource 140. In some examples, method 500 may end after block 528. In other examples, and as discussed above with respect to fig. 3, the processor 110 may prompt the user to forgo changes made by the user to the copy 132 of the external resource 140, or to force an override of the external resource 140 on the server 104. Processor 110 may receive a user instruction to force a version of external resource 140 to be overwritten with a version of copy 132 on device 102 that processor 110 may execute, and device 102 may acquire lock lease 134 again, as illustrated by arrow 330. Alternatively, processor 110 may receive a user instruction to abort a change made by the user to copy 132 of external resource 140, in which case device 102 may not discard lock lease 134 and may return to block 302.

Some or all of the operations set forth in methods 400 and 500 may be embodied as utilities, programs, or subroutines in any desired computer-accessible medium. Additionally, the methods 400 and 500 may be embodied by a computer program, which may exist in a variety of forms both active and inactive. For example, they may exist as machine-readable instructions, including source code, object code, executable code, or other formats. Any of the above may be implemented on a non-transitory computer readable storage medium.

Examples of non-transitory computer readable storage media include computer system RAM, ROM, EPROM, EEPROM, and magnetic or optical disks or tape. It will thus be appreciated that any electronic device capable of performing the functions described above may perform those functions enumerated above.

While specifically described throughout the entirety of the present disclosure, representative examples of the present disclosure have utility in a variety of applications, and the above discussion is not intended and should not be construed as limiting, but is provided as an illustrative discussion of aspects of the present disclosure.

What has been described and illustrated herein is an example of the present disclosure and some of its variations. The terms, descriptions and figures used herein are set forth by way of illustration only and are not meant as limitations. Many variations are possible within the spirit and scope of the disclosure, which is intended to be defined by the following claims and their equivalents, in which all terms are meant in their broadest reasonable sense unless otherwise indicated.