Supporting linked multi-user decision making in environments with constrained shared resources

Patent metadata

Field	Value
Publication number	US-9594793-B2
Application number	US-88881110-A
Country	US
Kind code	B2
Filing date	Sep 23, 2010
Priority date	Sep 23, 2010
Publication date	Mar 14, 2017
Grant date	Mar 14, 2017

Abstract

Embodiments of the present invention manage multiple requests to allocate real world resources in a multi-user environment. A request for interacting with a database environment comprising records of allocations of a plurality of resources is received from a user in a plurality of users. The database environment is shared between the plurality of users. A set of action choices available for the request is provided to the user via the user interface. A set of resources required by each action choice is identified. The set of resources is associated with a decision context. The decision context exists for a period of time. The set of resources are allocated to the user for a duration of the decision context. The allocating prevents the set of resources from being allocated to other users for the duration of the decision context irrespective of a set of actions performed by the other users.

First claim

What is claimed is:

1. A method for managing multiple requests to allocate real world resources in a multi-user environment, the method comprising:
receiving, from a user application in a plurality of user applications, a request to one open a file access block (FAB) to access and lock a file in a database, the file representing at least one resource shared among the plurality of user applications, and the request including open FAB input parameters of
an identifier of the file to access that is associated with the resource,
a search specification using one of a record identifier within the file or an index value within the file, and
a lock mode to access the file, the lock mode comprising one of
update a single record in the file with an exclusive lock,
update a single record in the file with an optimistic lock, and
read access to one or more records of the file;

allocating the FAB using the FAB input parameters and locking the file for a given amount of time based on the lock mode;
allocating an inner FAB, allowing the user application concurrent access to multiple files, wherein open multiple FABs are opened in a nested structure, wherein the inner FAB includes lock mode access that is different than the lock mode access of the FAB, thereby resulting in two nested FABS with different lock modes and lock holding times;
avoiding deadlock by ensuring that inner FABs only lock the files representing resources later in time in a resource ordering scheme than any other current locks held by the user application;
sending a search request to locate a record within the file and to either obtain one or more locks related to the record or to build a list of record identifiers;
receiving return data representing one of
a single record that is available for update, a single record for read access only, or a list of record identifiers;
sending the return data to the user application;
receiving, from the user application, a request to close the FAB with at least one FAB closing parameter that includes one of apply changes or discard changes;
sending a lock validation request to the database to ensure any locks in place related to the search specification are still valid;
applying updates to file data;
releasing any held locks independently on each file accessed by the user application, without waiting for other outer FAB data accesses to complete, such that when control exits from a FAB, file locks associated with that FAB are immediately released;
discarding any list of identifiers matching read only record keys identifiers; and
sending a success code to the user application.

2. The method of claim 1 , further comprising:
determining that at least one condition associated with the FAB that has occurred; and
de-allocating, in response to determining that at least one condition associated with the FAB has occurred, the file in the database, the de-allocating allowing other users in the plurality of users to access the file in the database.

3. The method of claim 2 , wherein the at least one condition comprises at least one of:
a given interval of time expiring; and
a given event occurring.

4. The method of claim 1 , further comprising:
determining that at least one condition associated with the FAB has occurred;
determining, in response to the at least one condition occurring, that the user has requested to close the FAB; and
permanently allocating the file in the database required by the request to close the FAB, which has been selected, to the user.

5. The method of claim 1 , further comprising:
storing a set of state information associated with the FAB in a durable file using short lived data update transactions.

6. The method of claim 5 , wherein the set of state information comprises information associated with at least one of:
a creation of the FAB;
an end of the FAB; and
the file in the database required by the request to close the FAB.

7. The method of claim 1 , wherein the allocating further comprises:
moving information associated with the file in the database between at least two durable data files, wherein each of the at least two durable data files is associated with an independent lock holding time.

8. The method of claim 7 , wherein each of the at least two durable data files represents a different allocation state of the file in the database.

9. A system for managing multiple requests to allocate real world resources in a multi-user environment, the system comprising:
a processor;
a memory communicatively coupled to the processor;
a decision base system communicatively coupled to the processor and the memory, wherein the decision base system is for performing:
receiving, from a user application in a plurality of user applications, a request to open a file access block (FAB) to access and lock a file in a database, the file representing at least one resource shared among the plurality of user applications, and the request including FAB input parameters of
an identifier of the file to access that is associated with the resource,
a search specification using one of a record identifier within the file or an index value within the file, and
a lock mode to access the file, the lock mode comprising one of
update a single record in the at least one file with an exclusive lock,
update a single record in the at least one file with an optimistic lock, and
read access to one or more records of the file;

allocating the FAB using the FAB input parameters and locking the file for a given amount of time based on the lock mode;
allocating an inner FAB, allowing the user application concurrent access to multiple files, wherein the open multiple FABs are opened in a nested structure, wherein the inner FAB includes lock mode access that is different than the lock mode access of
the FAB, thereby resulting in two nested FABS with different lock modes and lock holding times;
avoiding deadlock by ensuring that inner FABs only lock the files representing resources later in time in a resource ordering scheme than any other current locks held by the user application;
sending a search request the search specification to locate a record within the file and to either obtain one or more locks related to the record or to build a list of record identifiers;
receiving return data representing one of
a single record that is available for update, a single record for read access only, or a list of record identifiers;
sending the return data to the user application;
receiving, from the user application, a request to close the FAB with at least one FAB closing parameter that includes one of apply changes or discard changes;
sending a lock validation request to the database to ensure any locks in place related to the search specification are still valid;
applying updates to file data;
releasing any held locks independently on each file accessed by the user application, without waiting for other outer FAB data accesses to complete, such that when control exits from a FAB, file locks associated with that FAB are immediately released;
discarding any list of identifiers matching read only record keys identifiers; and
sending a success code to the user application.

10. The system of claim 9 , further comprising:
determining that at least one condition associated with the FAB has occurred; and
de-allocating, in response to determining that at least one condition associated with the FAB has occurred, at least one resource in the file in the database, the deallocating allowing other users in the plurality of users to access the file in the database.

11. The system of claim 10 , wherein the at least one condition comprises at least one of:
a given

Assignees

• Dantzig Paul M
• Dryfoos Robert O
• Duri Sastry S
• Gambino Mark
• Iyengar Arun
• Parr Francis
• IBM

Inventors

• Dantzig Paul M
• Dryfoos Robert O
• Duri Sastry S
• Gambino Mark
• Iyengar Arun
• Parr Francis

Classifications

• G06F16/2343 Primary

  Locking methods, e.g. distributed locking or locking implementation details · CPC title

• G06F17/30362 Primary

  Physics · mapped topic