1	Name: activelock
	Namespace: DAV:
	Purpose: Describes a lock on a resource.
	Description: This element describes an active lock on a resource.
	Although shown as having owner, timeout and expectedlifetime
	properties, other properties may also exist, such as lockscope,
	locktype, depth, etc.
	<!ELEMENT activelock (owner?, timeout?, expectedlifetime?)>
2	Name: expectedlifetime
	Namespace: DAV:
	Purpose: Defines how long the client expects to hold the lock without
	explicitly unlocking or modifying the lock.
	Value: Time value, such as “TimeType” used for the timeout
	property.
	<!ELEMENT expectedlifetime (#PCDATA)>

As shown in Table 1, the new expectedliftetime property has been defined for DAV. The expected lifetime request header defines a time value, such as an integer value related to the number of seconds the client expects to use the resource. The request header may appear as follows: Expectedlifetime=“Expectedlifetime” “:” 1#TimeType. Unlike timeout request headers, an expectedlifetime request header has a single value.

As discussed above, the expected lifetime information may be delivered to a subsequent client application program in response to a request for the locked resource. The client, in turn, may use this information to determine when to repeat the request for the resource. By determining when to repeat the request, the client application program may improve its performance by freeing resources for other tasks that might otherwise be used in requesting a resource during a timeframe in which the resource is most likely locked and therefore unaccessible.

While the expected lifetime information allows the client to better determine when to repeat a request, theservices layer314 may also, or alternatively, include a blocking module334, which blocks future requests for a particular, locked resource. That is, when a client application program locks a resource and another client application issues a request for that resource and that request is denied due to the existing lock, the later client application program may establish a block for the resource. The block operates to prevent other client applications from obtaining the resource. More particularly, the block operates to prevent others from obtaining the resource after the initial client application program has unlocked the resource thereby allowing the subsequent client application program which established the block to access the resource.

In order to establish a block, the client application program indicates that such a block should be created. Next, the blocking module334 may store an identification value for the blocking client application program. Since all requests for the resource go throughlayer314, thelayer314 and its blocking module334 does not allow any other client application programs to gain access to a blocked resource. Once the resource is free of the conflicting lock, the blocking module334 may then notify the client that established the block of the status of the resource to allow that client to make another request. Alternatively, the blocking module334 may actually provide access to the resource once the resource is free.

Once a block is in place, in order to determine the status of a resource, the blocking module334 may automatically and repeatedly poll the resource to determine its status, e.g., locked or free. Alternatively, the blocking module may simply wait for future requests for the resource, whether made by the blocking client application program or another, and make the determination at that time. In the latter case, the blocking application program would most likely be set to repeatedly request the resource to ensure access. Blocking in this manner allows clients to avoid the starvation issues associated with polling lock acquisitions.

In an embodiment, such as in the DAV environment, the requesting client may supply a “block header” to the server to indicate that a block should be established. In a particular embodiment, a “maxwaittime” request header may be used. The maxwaittime header has the same value format as the timeout request header and is used primarily in lock and update lock requests. The maxwaittime header indicates a time period for blocking the resource, which is related to the time that the client is willing to wait for the lock to be unlocked. The request header may appear as follows: Maxwaittime=“Maxwaittime” “:” 1#TimeType. The header must have at least one value and may have several as is the case with timeout request headers in DAV.

Once received, the services layer modifies the lock object to include the max wait time valve as a stored property within, or associated with, the lock object. This allows others to simply test the lock to determine whether another client has created a block and for how long.

In some cases, waiting for a lock to be freed, either by timing out or by an exclusive unlock event is not sufficient. Thus, theservices layer314 may also comprise abreaking module336, which provides a lock breaking function. In essence, given that locks in certain protocols, such as DAV, can have infinite timeout or lifetime periods, there must be a way to break a lock, especially under certain situations, e.g., where a client has orphaned the resource and is unable to unlock the resource. In order to break a lock, however, the breaking module may first determine whether the resource has actually been orphaned or whether the resource is still in use. If the resource is still in use, the server may send a notice to the owner indicating the impending lock break function. Additionally, since thebreaking module336 may also break locks on resources that have not been orphaned, the breaking module may perform a security check to ensure that the requesting application program has adequate security clearance to perform the breaking function.

In an alternative embodiment, thebreaking module336 can not only break locks, i.e., completely eradicate a lock object, but can also modify the remaining lifetime of a lock to effectively cause the end of a lock at a predetermined time. In such a case, the modification may also test for security clearance and/or provide the lock owner with information related to the modification to its lock.

In order to implement the breaking module, i.e., the ability to break a lock, the protocol, such as DAV, is extended to allow clients or other principals to issue an “unlock” request for a lock token originally acquired by another principal. In order to prevent mistakes, the unlock request may specifically indicate that a lock break is intended within a new request-header. Furthermore, the request should be able to specify a latency before the break actually occurs to allow the server computer system to notify the client that owns the lock that a break is about to occur and give it sufficient time to store any pending changes covered by that lock.

In order to achieve these functions, a “breaklatency” request header may be implemented in the protocol. The breaklatency header is used in unlock requests made by those other than the lock owner and indicates how long the server should wait before actually breaking the corresponding lock. The presence of a breaklatency header indicates that the request is not a normal unlock request, i.e., an unlock request made by the existing lock owner. In an embodiment, the server is not required to wait the requested latency period. Prior to breaking the lock, the server may return a status code indicating the perceived likelihood of whether the unlock request, i.e., the lock break will succeed. Alternatively, the server sends a response following the breaking of the lock, if at all.

In an embodiment, such as the DAV environment, the breaklatency request header may appear as follows: BreakLatency=“Breaklatency” “:” 1#TimeType. Unlike a timeout request header, the breaklatency request header has one value. The following table, Table 2, includes an example of the breaklatency request header. In this example the latency is 60 seconds and the request succeeds. The “204” code is used for successful unlock responses. In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.

TABLE 2


Example Use of a Breaklatency Request Header

	>>Request
	UNLOCK /container/ HTTP/1.1
	Host: webdav.microsoft.com
	Breaklatency: Second-60
	Lock-Token: <opaquelocktoken:
	e71d4fae-4may-22d6-fea5-00a0c91e6be4>
	Authorization: Digest username=“jgoldick”,
	realm=“jgoldick@webdav.microsoft.com”, nonce=“...”,
	uri=“/container/”,
	response=“...”, opaque=“...”
	>>Response
	HTTP/1.1 204 No Content

In an alternative implementation, suitably privileged or authorized principals are allowed to issue a lock or an update-lock request that effectively reduces the timeout of an existing lock owned by another client. The server may perform the decision as to which principal(s) may be suitably authorized, i.e., it may be a server-level decision. Alternatively, the developer may also provide an indication as to which systems may be authorized. If the original lock owner fails to request access that would result in the lock being refreshed, an effective lock break will have occurred. In order to implement locking and updating by others, the breaklatency request header may be used in lock and update-lock requests. Furthermore, the presence of the breaklatency request header indicates that the request is by one other than the lock owner and therefore normal security checks do not apply, and stricter checks may be implemented.

More details of an update lock technique that may be used to change a breaklatency request may be found in the U.S. patent application Ser. No. 09/992,525, entitled METHOD AND SYSTEM FOR MODIFYING LOCK PROPERTIES IN A DISTRIBUTED ENVIRONMENT, incorporated herein by reference for all that it discloses and teaches, filed concurrently herewith, and assigned to the Assignee of the present application.

FIG. 4 is a flow chart of the operational characteristics related to allocating resources, returning information related to a locked resource and blocking locked resources. Prior to the beginning offlow400 an object, such asobject304 and/or306 shown inFIG. 3, may already exist within a Server System Resource Store, such asstore302. In such an embodiment, once the object has been created, then any later attempt to access that object initiates theflow400 shown and described with respect toFIG. 4. In an alternative embodiment however, e.g., such as when the DAV protocol is used, the object may not exist prior toflow400. In such a case, a lock object may be created in parallel with the creation of a data object, or the lock object may be created and later associated with the data object once the data object is created.

Process

400 generally begins with receiveoperation402, wherein the receiveoperation402 relates to the receipt, by the server system of any access request related to an object. The access attempt may be performed by a third party application, such asapplication318 or320 (FIG. 3) or by theservices layer314, among others. The access request incorporates information related to the type of access that is being requested, i.e., to read, to write, to delete, etc. Additionally, the request information may also include information as to the type of lock to be created and applied while the object is in use. Moreover, the request information may also include a request for existing lock information if a conflicting lock exists, blocking information and or breaking information as discussed below.

Following receiveoperation402,determination act404 determines whether the access may be allowed by determining whether a conflicting lock exists. A conflicting lock is a lock owned by another client application program and wherein the scope of the lock is set such that the subsequent request cannot be allowed, e.g., the lock is an exclusive lock or the lock only allows others to read the resource but the subsequent request is to write to the resource. The term conflicting lock is used since some locks may not conflict with subsequent requests since locks may provide limited sharing capabilities, e.g., where the lock allows others to read the resource and the subsequent request is to read the resource.

Determining whether the resource has a conflicting lock, in an embodiment of the invention, involves requesting lock properties from the resource object itself. In such a case, the resource may be associated with a lock object, such asobjects308 and310 (FIG. 3) and the lock objects may be evaluated to determine the type of lock, if any, presently being enforced for the requested resource. In other embodiments, the determination relates to an evaluation of a look-up table that is managed by theservices layer314. Yet other embodiments may incorporate other means of providing information related to whether an object is locked and, if so, the type of lock.

Ifdetermination act404 determines that the requested resource may be accessed, i.e., that no conflicting lock exists, flow branches NO to provide-access operation406. Provide-access operation406 provides the requesting client application access to the requested resource. Additionally, operation406 may perform the creation and/or association of a new lock object or other lock-related data structure with the requested object. The type of lock object that is created relates to the type requested by the client application. Further, should a lock be created by operation406, then the lock object generated by operation406 may then be evaluated during other access requests until the lock object is removed or invalidated. Following operation406, flow400 ends at408.

Ifdetermination act404 determines that the requested resource may not be accessed, i.e., that a conflicting lock exists, then flow branches YES to parseoperation410. Parseoperation410 parses the incoming request to determine if the request has headers or other indicators that information is requested, that a block is requested, etc. Once parsed,determination operation412 determines whether the request includes a request for lock information.

If the request includes a request for information, then flow branches YES tooperation414 which returns requested lock information, such as expected lifetime or type and scope information. In alternative embodiments,return operation414 automatically returns lock information regardless of whether the initial request asks for this type of information. However, given that some client applications are not prepared to use such information, it may be preferred to perform thetest operation412 to determine whether the client application desires such information.

The type of information returned to the client application may be either a value related to the expected lifetime of the lock, as set by the lock owner, or it may also relate to the type and scope of the lock. This information allows the client to tailor its next request for the resource, either to a request that does not conflict with the existing lock or to adjust the timing of the next request to increase the probability that the resource will be free at that time.

Following the return oflock information operation414, the flow ends atend operation408.

If determineoperation412 determines that the request does not include a call for returned lock information then flow branches NO to testoperation416, which determines whether a block should be established. Alternative embodiments may determine whether a block should be established independently ofdetermination operation412, e.g., following parseoperation410.Test operation416 tests the initial request to determine whether a block should be placed on the resource. If not, then flow branches NO to endoperation408. In other embodiments, the client may send a subsequent request intended to actually establish the block and this subsequent request is analyzed by an operation similar to testoperation416.

One method of determining whether a block should be established relates to testing the initial request for the existence of a “maxwaittime” header. The mere presence of a maxwaittime header may indicate the desire to establish a block. Alternative embodiments may have predetermined flags that can be set to indicate the desire to establish a block. In yet another embodiment, a message may be sent to the client inquiring as to whether a block should be set. In such a case the response to the inquiry is evaluated to determine whether a block should be established.

If a block should be established, as determined byoperation416, flow branches YES to establishoperation418. Establishoperation418 establishes the block for a particular resource. In such a case any further or subsequent requests for that resource by any other client application programs other than the block owner are denied. The block itself may be another type of property associated with the resource that can be evaluated to determine if a requesting client should be allowed access to a resource. In an alternative embodiment, only requests for conflicting locks cause a denial, such that the block is effective against potentially conflicting lock requests but does not cause a denial of access when the resulting access does not conflict.

In an embodiment, the block has a lifetime established by the blocking client. Upon expiration of the lifetime of the block,operation420 determines whether a conflicting lock still exists on the requested resource. If not, then flow branches NO to provide operation406, which allows access to the resource. If so, then a message is sent to the client application to indicating that the block has expired and that the lock still exists and then flow branches YES to endoperation408.

In another embodiment, once the lock is released or harvested by the server computer system, then the block provides an indication that the subsequent client is interested in obtaining access to the resource. In such a case, the server can then inform the subsequent or blocking client that the resource is free. Thus, the block acts as a subscription to a lock-related event. This type of service may be provided in combination withdetermination act420 shown inFIG. 4.

In accordance with other aspects of the present invention, the services layer may provide services related to breaking and/or modifying existing locks.FIG. 5 is a flow chart of the operational characteristics related to breaking or modifying an existing lock object. As described above with respect toFIG. 4, prior to the beginning offlow500 an object, such asobject304 and/or306 shown inFIG. 3, exist within a Server System Resource Store, such asstore302.

Flow

500 begins with receiveoperation502, wherein the receiveoperation502 relates to the receipt, by the server system of any read, execution, or update access request for an object. The access attempt may be performed by a third party application, such asapplication318 or320 (FIG. 3) or by theservices layer314, or by yet other client-type requesting entities. The request itself may include information as to the type of access sought, any lock types to be created and enforced during the access, and/or a request for a lock token, etc. Additionally, the request may indicate whether an existing lock should be broken and/or modified, if one is present. Alternatively, the received request may simply be a request to break or modify a lock, apart from a request to access a resource.

Once the request has been received,determination act504 determines whether the requested resource is locked. Thus,determination act504 determines whether the resource is locked by another client application program by either searching for a lock object associated with the resource, analyzing properties of the resource object itself, or by searching for lock information in a look-up table type of data structure. In either situation, the server analyzes any lock information for the requested object and determines whether an associated lock conflicts with the type of access requested. In the alternative embodiment wherein the request relates to a request to break or modify a lock, thendetermination act504 simply determines whether the lock exists.

Ifdetermination act504 determines that the type of request does not conflict with any lock objects associated with the requested object, flow500 branches NO to provide-access operation506. Provide-access operation506 is similar to provide operation406 described above in conjunction withFIG. 4 and may also include creation of a lock for the requesting client. Once access has been provided, then flow500 ends atend operation508.

In alternative embodiments wherein the request is to break a lock, provide operation506 may send a message to the client that the lock does not exist and flow branches to endoperation508.

Ifdetermination act502 determines there is a lock associated with the requested resource that conflicts with the requested access, then flow500 branches YES to testact510.Test act510 tests the request to determine whether the lock should be broken outright. Testing whether the lock is to broken relates to checking the request for an indication that lock should be broken, e.g., by the presence of breaklatency header. If this header is present, then flow branches YES to checksecurity operation512.

Checksecurity operation512 determines whether the client application program has the requisite capabilities to perform the lock break. If not then the process ends and the lock is not broken. However, if the client application program does have the requisite security then the lock may be broken (or modified). In an embodiment, determining whether a client application program has the requisite security clearance involves testing the request to break the lock. In the request, the client application program may include information related to the whether the client can read or write to the resource. Depending on the level of permission allowed the client, the server may determine if the security check has been satisfied. Although a security check should be done to prevent uncontrolled lock harvesting, it is not necessary to the understanding of the present invention and practically any number of security validation techniques may be used to determine whether the client is able to break a lock.

Following thesecurity check operation512, notifystep514 notifies the lock owner that the lock is about to be broken or modified. Notifying the lock owner of an impending lock break may provide the owner time to perform a lock refresh action or some other action that may stop the break function. Alternatively, the notification may provide the owner time to perform another action, e.g., a save to prevent lost updates. Notifystep514 is an optional step in that some server systems may not notify the owner of the lock, yet such a notification may be preferred to protect owners from lost updates.

Once the notification has been completed, break operation516 breaks the lock. Following break operation516, flow500 ends atend operation508.

Iftest act510 determines that the request does not indicate that the lock should be broken, e.g., by the absence of a predetermined header, then flow branches NO to testoperation518.Test operation518 tests the initial request to determine whether the lock should be modified. Such a modification may relate to actually reducing the timeout period or modifying the sharing capabilities of the lock. The modification may, in essence, change the properties of a lock to thereby enable another client to access the resource. Determining whether the initial request includes a request to modify the lock may involve a test for the presence of an “update” or “modify” lock header in the request. The mere presence of one of these headers may provide the server an ability to determine whether the request is for modification of the lock.

Iftest operation518 determines that the request does not request lock modification, then flow branches NO to endoperation508. However, iftest operation518 determines that the lock is to be modified, then flow branches YES to checkoperation512. Checkoperation512, as discussed above determines whether the client application program requesting the lock modification has the requisite security to perform such an action. Once the security check has completed, notifyoperation514 notifies the lock owner that a modification is about to occur. As discussed above, notify operation is optional but may provide the lock owner time to perform a save or refresh act to prevent loss.

Following the notification, modify operation516 performs the lock modification. The lock modification process may involve changing the locks properties, e.g., the timeout value, the sharing capabilities, etc. In alternative embodiments, the modification process may involve creating a new lock object, associating the new lock object with the resource and then deleting or harvesting the old lock object. In yet other embodiments, the actual modification process may be performed in other ways, but the end result is a lock object having different or modified properties. Once modified, flow500 ends atend operation508.

The above described system and method provides a significant advantage over prior methods of managing resource locks in a distributed environment. In particular, the communication of both expected lifetime information for a lock significantly improves the planning and selection of request timing issues and performance for client application programs. Additionally, the ability to block a resource pending an unlock event further increases performance for client applications. The breaking and modification of existing locks also improves overall control of lock allocation and management.

As discussed above, the invention described herein may be implemented as a computer process, a computing system or as an article of manufacture such as a computer program product. The computer program product may be a computer storage medium readable by a computer system and encoding a computer program of instructions for executing a computer process. The computer program product may also be a propagated signal on a carrier readable by a computing system and encoding a computer program of instructions for executing a computer process.

Additionally, although the invention has been described in language specific to structural features and/or methodological steps, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific features or steps described. Therefore, the specific features and steps are disclosed as preferred forms of implementing the claimed invention.