International Business Machines Corporation

Michael Leo Walker

David Allan Pease

Toby Lyn Marek

David R Nowlen

Linda Marie Duyanovich

James Vernon Carlson

Paul Harold Hilton

An indication of refusal of a lock request is received with a first operation identifier for a resource that is already locked with a lock associated with a second operation identifier from an agent that controls the resource, wherein the agent returns a value that determines how long the lock request is to stay on the queue. The lock request is placed in a queue with a lock queue timeout period based on the value from the agent. The lock request is reissued if the lock associated with the second operation identifier has been released and the lock request reaches a position of the queue from which the lock request is processed within the lock queue timeout period. The lock request is re-queued if the reissued lock request is not granted based on how many times the lock request has been previously placed in the queue.

Managing locks and transactions

A policy-based data management system, method, and apparatus are disclosed. The system, method, and apparatus are configured to operate over a distributed storage system such as a storage area network (SAN). Files to be stored on the network are each assigned a service class and a storage pool based on the application of policies to file attributes such as file name, type, user, etc. The service class and storage pool designations are stored as metadata. Files may be retrieved using the metadata to identify the storage pool where the file is stored, and the service class listed within the metadata may be used to control the manner in which the file is handled. A metadata server may be utilized to provide the appropriate service class of files in response to requests from remote clients that may be of different computing platforms.

System, method, and apparatus for policy-based data management

Disclosed is a method, system, and program for lock management. Under control of a lock manager, lock request queuing is performed, heartbeat functions are performed, and state information is maintained.

Lock and transaction management

Under control of a first agent, a resource controlled by a second agent is locked with a first operation identifier. Under control of the second agent: a request is received to lock the resource controlled by the second agent with a second operation identifier for a client request for a client application, wherein the resource is already locked with the first operation identifier; it is determined whether the first operation identifier and the second operation identifier are determined to be a same identifier; if it is determined that the first operation identifier and the second operation identifier are the same identifier, the request is responded to with an indication that the resource is locked with the same operation identifier; and, if it is determined that the first operation identifier and the second operation identifier are not the same identifier, the lock request is denied.

Disclosed is a method, system, and program for locking management. A command is received that specifies an operation identifier. It is determined whether the command is associated with a transaction using the operation identifier. If it is determined that the command is associated with a transaction, operating at a transaction level of locking. Further disclosed is a method, system, and program for lock management. Under control of a lock manager, lock request queuing is performed, heartbeat functions are performed, and state information is maintained.

Method, system, and program for lock and transaction management

A request is received with a first operation identifier to lock a first resource. The first resource is locked with the first operation identifier. It is determined whether a second resource should be locked with the first operation identifier or with a second operation identifier based on whether an operation to be performed for the request may complete after the request is processed. Additional embodiments are described and claimed.

Method, system, and program for managing locks and transactions

Disclosed is a method, system, and program for transaction management. An indication is received that a transaction is beginning. An operation identifier for the transaction is generated. Actions are logged for the transaction identified by the operation identifier, wherein the actions include requests, corresponding reverse requests, and locks granted. Also disclosed is a method, system, and program for locking management. A command is received that specifies an operation identifier. It is determined whether the command is associated with a transaction using the operation identifier. If it is determined that the command is associated with a transaction, operating at a transaction level of locking. Further disclosed is a method, system, and program for lock management. Under control of a lock manager, (i) lock request queuing is performed, (ii) heartbeat functions are performed, and (iii) state information is maintained.

Growing community of inventors

Topeka, IL, United States of America

Michael Leo Walker