Source: http://www.google.com/patents/US5408653?dq=actionscript
Timestamp: 2017-09-20 04:17:15
Document Index: 725977548

Matched Legal Cases: ['art 1', 'art 1', 'art 1', 'art 2', 'art 1', 'art 2', 'art 1', 'art 2']

Patent US5408653 - Efficient data base access using a shared electronic store in a multi-system ... - Google Patents
A computer-implemented method for minimizing the amount of time to access current data in a database which may be stored wholly in a DASD-oriented external storage subsystem or partly in DASD and partly in a stored high-speed electronic store while maintaining coherency of the data with respect to multiple...http://www.google.com/patents/US5408653?utm_source=gb-gplus-sharePatent US5408653 - Efficient data base access using a shared electronic store in a multi-system environment with shared disks
Publication number US5408653 A
Application number US 07/869,267
Also published as US5557792, US5761660
Publication number 07869267, 869267, US 5408653 A, US 5408653A, US-A-5408653, US5408653 A, US5408653A
Inventors Jeffrey W. Josten, Tina L. Masatani, Chandrasekaran Mohan, Inderpal S. Narang, James Z. Teng
Patent Citations (13), Non-Patent Citations (4), Referenced by (106), Classifications (19), Legal Events (4)
Efficient data base access using a shared electronic store in a multi-system environment with shared disks
US 5408653 A
1. In a database system including a plurality of database management systems (DBMS's), direct access storage connected to the DBMS's for storage of one or more databases, and a shared store connected to the DBMS's to temporarily store data for rapid access by the plurality of DBMS's, wherein:
said DBMS's provide data from one or more databases to transactions for database processing:
a method for maintaining coherency of a database with respect to said plurality of DBMS's, the method comprising the following steps:
(1) responsive to a request by a first transaction to a first DBMS for data from a designated database, the request being in the absence of any other transaction requests to any other DBMS for updating the designated database:
(1a) at the first DBMS, obtaining the data from the direct access storage without checking for the data in the shared store;
(1b) executing the first transaction by conducting a transaction operation at the first DBMS; and
(1c) committing the first transaction; and following the commitment of the first transaction:
(2) responsive to a request by a second transaction to the first DBMS for data from the designated database, the request being substantially concurrent with a request by a third transaction to a second DBMS for updating the designated database;
(2a) at the first DBMS, if the data requested by the second transaction is in the shared store, obtaining the data from the shared store, otherwise obtaining the data from the direct access storage;
(2b) executing and committing the third transaction at the second DBMS;
(2c) synchronously with the commitment of the third transaction, writing data updated by the third transaction from the second DBMS to the shared store.
2. The method of claim 1, wherein in step (2) the request by the second transaction is a request for updating data in the designated database, step (2a) including:
(2ai) first, exclusively locking a data object in the designated database to be updated by the second transaction for the first DBMS;
(2aii) next, if the data object is in the shared store, obtaining the data object from the shared store, otherwise obtaining the data object from the direct access storage;
(2aiii) further, executing and committing the second transaction on the data object at the first DBMS;
(2aiiii) synchronously with commitment of the second transaction at the first DBMS, writing the data object to the shared store; and
(2av) then, unlocking the data object.
3. The method of claim 1, step (1b) further including:
(1bi) executing an updating operation on the data at the first DBMS; and
(1cl) asynchronously with the commitment of the first transaction, writing the data to the direct access storage.
4. The method of claim 1, wherein step 2(c) further includes providing notification of updating the data at the second DBMS to all other DBMS's.
5. In a database system including a plurality of database management systems (DBMS's), direct access storage connected to the DBMS's for storage of one or more databases, a shared store connected to the DBMS's to temporarily store data for rapid access by the plurality of DBMS's, and a locking mechanism for granting access to a database, a method for maintaining coherency of a database with respect to said plurality of DBMS's, the method comprising the following steps:
granting sole access to a first DBMS for acquiring data from a designated database;
at the first DBMS, during said sole access, obtaining the data from the direct access storage;
executing a transaction operation on the data at the first DBMS;
during said sole access, generating a request for access to the designated database from a second DBMS;
responsive to the request from the second DBMS, writing updated data of the designated database from the first DBMS to the direct access storage and removing all non-updated data of the designated database from the first DBMS; and
changing the sole access of the first DBMS and granting the second DBMS access to the designated database.
6. The method of claim 5, wherein the second granting step includes granting shared access to the second DBMS for updating the designated database, further including:
changing the sole access of the first DBMS to shared access;
at the second DBMS, updating data of the designated database and writing the updated data of the designated database to the shared store; and
at the first and second DBMS's, obtaining required data of the designated database from the shared store or from the direct access storage if the required data is not in the shared store.
at the second DBMS, surrendering access to the designated database;
changing the access of the first DBMS to sole access;
at the first DBMS, during said sole access, obtaining data from the direct access storage.
8. The method of claim 5, wherein the second granting step includes granting shared access to the database for reading pages in the designated database, further including:
changing the access of the first DBMS to shared access;
at the first DBMS, obtaining pages of the designated database without locking the pages;
updating the pages at the first DBMS and writing the updated pages to the shared store; and
at the second DBMS, obtaining pages of the designated database from the shared store or from the direct access storage if the pages are not in the shared store.
9. The method of claim 5, wherein before the step of generating a request from the second database:
the step of obtaining data from the direct access storage includes obtaining pages of the designated data base without locking the pages; and
the step of executing a transaction includes updating the pages; the method further including:
returning updated pages from the first DBMS to the direct access storage.
10. In a database system including a plurality of database management systems (DBMS's), direct access storage connected to the DBMS's for storage of one or more databases, a shared store connected to the DBMS's to temporarily store data for rapid access by the plurality of DBMS's, a log mechanism for each DBMS in which transaction records are written in a monotonically-increasing sequence, and a locking mechanism for granting access to a database by a locking procedure in which a lock on a designated database is granted to a requesting DBMS, the lock being conditioned to denote:
a first mode in which a single DBMS is updating data resources in the designated database; or
a second mode in which two or more DBMS's have been granted access to update data resources in the designated database;
a method for recovery of the designated database in response to failure of the shared store, the method executed while writing transaction records of incremental changes to the designated database to the logs of all DBMS's having access to the designated database, and including the steps of:
(a) at a first DBMS which holds the lock in the first mode, writing updates of the designated database to the direct access storage;
writing a database conversion log record denoting a change of the designated databases from a non-store-dependent state in which updates to the designated database are written to the direct access storage to a store-dependent state in which updates to the designated database are written to the shared store;
writing to the direct access storage all updates of the designated database which have not yet been written to the direct access storage; and
downgrading the lock to the second mode;
(e) at the first and second DBMS's, writing to the shared store all updates of the designated database;
(f) in the event of a failure of the shared store, inspecting the mode of the lock, and:
marking the designated database as store dependent in response to the second mode of the lock;
recovering the designated database using transaction records in the DBMS's logs; and
barring access to the designated database in response to the store dependent marking until recovery is completed.
11. The method of claim 10, wherein in the event of failure of the shared store and the locking mechanism the following steps are performed instead of step (f):
inspecting the logs of all DBMS's for store dependent entries;
in response to the store dependent entry for the designated database, marking the designated database as store dependent;
barring access to the designated database during recovery processing in response to the store dependent marking until recovery is completed.
before failure of the shared store;
granting the lock in the second mode to a plurality of DBMS's, updating the designated database and then surrendering the lock at the plurality of DBMS's until a single remaining DBMS holds the lock in the second mode; and
at the single remaining DBMS, writing all updates for the designated database which are in the shared store to the direct access storage, purging the updates from the shared store, writing a database conversion log record denoting a change of the designated database from the store dependent to the non-store dependent state, and upgrading the lock to the first mode in which the single remaining DBMS is updating the designated database; and wherein step (f) now includes:
in the event of failure of the shared store, inspecting the mode of the lock and marking the designated database as non-store dependent in response to the first mode of the lock, recovering any databases which are store dependent, and permitting access to the designated database during the recovery process; otherwise,
if the lock fails, inspecting the logs of the DBMS's for database conversion log records and, in response to the database conversion log record denoting a change in the designated database from a store-dependent to a non-store dependent state marking the designated database as non-store dependent, recovering all store-dependent databases, and permitting access to the designated database during recovery.
This application is related to U.S. patent application Ser. No. 07/628,211, now U.S. Pat. No. 5,267,835 filed Dec. 14, 1990, entitled "NON-BLOCKING SERIALIZATION FOR CACHING DATA IN A SHARED CACHE", commonly assigned with this application; U.S. patent application Ser. No. 07/627,315, now U.S. Pat. No. 5,287,473 filed Dec. 14, 1990, for "NON-BLOCKING SERIALIZATION FOR REMOVING DATA FROM A SHARED CACHE", commonly assigned with this application; U.S. patent application Ser. No. 07/656,567, filed Feb. 15, 1991, for "FAST INTER-SYSTEM PAGE TRANSFER IN A DATA SHARING ENVIRONMENT WITH RECORD LOCKING", commonly assigned with this application; U.S. patent application Ser. No. 07/790,241, now U.S. Pat. No. 5,301,290, filed Dec. 8, 1991, for "METHOD FOR MANAGING DATABASE RECOVERY FROM FAILURE OF A SHARED STORE IN A SYSTEM INCLUDING A PLURALITY 0F TRANSACTION-BASED SYSTEMS OF WRITE-AHEAD LOGGING TYPE", commonly assigned with this application; U.S. patent application Ser. No. 07/493,562, now U.S. Pat. No. 5,301,290, filed Mar. 14, 1990, for "HIERARCHICAL INVALIDATION FOR DISTRIBUTED CACHES", commonly assigned with this application; U.S. patent application Ser. No. 07/512,615, priority date Mar. 13, 1987, for "DYNAMIC SOLE INTEREST IN MULTIPLE SYSTEM LOCKING WITH HIERARCHIES", commonly assigned with this application.
In a database system wherein a plurality of independently-operating computer systems-share data, global locking is employed to maintain coherency of data with respect to the different systems. A. J. Gore, in COMPUTER ARCHITECTURE AND DESIGN, Addison Wesley, 1989, discusses the data coherency problem as one in which sharing data among a proliferation of processors raises the possibility that multiple, inconsistent copies of data may exist because of multiple paths to the data resulting from multiple opportunities to locally modify the data.
In summary, informing the DBMS of the level of inter-system interest in the multi-system environment of FIG. 1 provides several significant and unexpected optimizations. When operating at level A interest, a DBMS can follow a no-force-at-commit policy. Significantly, this means that when only one DBMS is accessing a database and is updating that database, it can follow a no-force-at-commit policy and group I/O operations with DASD for batch processing and without the requirement to synchronize the writing of each update to DASD with commitment of the updating transaction. When a DBMS is operating at level A interest, global page-cache locking is not required. When operating at level B interest, only one system is updating; therefore, that one system is not required to obtain a page-cache lock to serialize concurrent updates to the page.
In the preferred embodiment, the DBMS is informed as to current state and change in inter-system interest by the GLM, using an in-place hierarchical locking scheme for caching pages of a database. In the preferred embodiment, the hierarchy includes a database-P (physical) lock on a database, from which page-P locks on database pages descend. In the invention, the BM exploits this hierarchical locking scheme for adapting to the changes of inter-system interest in a database. In the invention, BM locking on a database is different than transaction locking on objects. The purpose of BM locking is to maintain cache coherency in a multi-system environment and has no meaning in a single system environment. The P locks are system level locks, not transaction level locks. Furthermore, in the invention, BM locks are negotiable in that the LLM is made aware that in the case of contention or other activity with reference to a database-P lock, a BM procedure (a "P lock exit") must be invoked. The negotiability of the database-P lock enables a BM to react dynamically to a change of inter-system interest. Management of the inter-system P locks by the global lock manager is discussed below.
FIG. 2 illustrates the essential steps of the invention for a given DBMS. Initially, access will be sought to a database which has not been opened at the DBMS. The request is denoted in step 40. While the database is being opened at this DBMS, BM locking on the requested database will be inspected in step 42 to determine whether another system is currently using the database. If not, the database is acquired, opened, a database-P lock is acquired and tabled at the GLM 33 and the negative exit is taken from decision 42 to step 43. In step 43, in the absence of any other interest in the database, the using DBMS can manage its buffer according to a no-force policy and can dispense with the acquisition of page-P locks for updates to pages in this database. Since the database-P lock is negotiable, any time another system requests (block 44) the database-P lock in a mode which is incompatible with existing held modes, or which causes a change in the resultant mode, the GLM 33 will inform the DBMS. The other DBMS's request is evaluated in step 45. If the request is such that it would result in intersystem read/write (level B) interest or in intersystem write-write (level C) interest, the positive exit is taken from step 45 and the buffers of all DBMS's accessing this database will be managed by a force policy in which pages with committed updates are written to the shared store by the updating system and requests for pages from this database are satisfied by looking first to the shared store and then to the DASD. A necessary step of this force policy is notifying other systems of updates to pages. Such notification can be direct by inter-system message transfer, in which the updating system informs the other systems of the update and the other systems acknowledge the message. The data sharing mode of the IMS products available from the assignee employs this technique by means of a "buffer invalidation message". Alternatively, information signifying page update by one system can be provided to all other systems by means of information maintained at the GLM for this purpose. In this regard, see, for example, the third incorporated U.S. Patent Application in which a version number denoting the latest update of a buffered page is compared against a global lock manager version number for the page which is incremented every time a buffered version of the page is updated. In step 47, if more than one system holds a database-P lock for updating this database, the BM's for all updaters must acquire page locks. Otherwise, if only one system is updating while multiple systems read, the updating system need not acquire page locks. If, at any time that the DBMS is in step 47, the database-P lock is released (block 48) all other systems holding it (level C interest, decision 50) the DBMS can return to the policy optimizations of step 43. Otherwise, the policies of step 47 are maintained.
Part 1 of Table I is a pseudo code illustration of logic in DBMS2 for acquiring the database-P lock in IS mode (for reading the database) or IX mode (for updating the database) while DBMS1 holds the database-P lock in X mode. In Part 1, the lock called "store-dependent conversion lock for DBI" (a different lock than database P lock) is acquired in S mode by DBMS2 if the intent is only to read, and in X mode if the intent is to update the database. The purpose of the store-dependent conversion lock is to serialize the process in DBMS2 which acquires the P lock with DBMS2's P lock exit which might be called by DBMS's request for the database lock before DBMS2 has marked the cached state in its database control block.
(a) 37 database-open" log record: written on the first update with an indicator telling whether or not the database was "store-dependent".
(d) 37 database close" log record: written at database close.
TABLE I______________________________________(Part 1)101  IF the database-P lock is requested in IS mode THEN/=DBMS2 needs to perform read only                         =//=access to the database      =/102  Acquire the database "Store-Dependent" conversion lock in S mode/=This lock is used to serialize                         =//="Store-Dependent" and "Non-Store-                         =//=Dependent" conversion for a database                         =/103  ELSE  /=DBMS2 needs to update the database                             =/104  Acquire the database "Store-Dependent" conversion lock in X mode/=Acquire lock in X mode to ensure                         =//=that only one member is performing                         =//=the "Store-Dependent" conversion                         =/105  Acquire the database P-lock in IS/IX mode/=LLM/GLM triggers DBMS1 lock exit                         =//=(due to lock conflict to downgrade                         =//=the database-P lock to SIX/IX                         =//=DBMS2 will not get control until                         =//=DBMS1 has downgraded the database-P                         = //=lock to SIX (IS lock request) or                         =//=to IX (IX lock request      =/106  IF the database-P lock is requested in IX mode THEN107  Write a "Database Open" log record and force it to the log data set to indicate the database is "Store-Dependent"/=this log record is used by DBMS to                         =//=determine whether or not the                         =//=database was "store-Dependent" when                         =//=database-P locks are lost.  =/108  ELSE /=IS lock request, do nothing                             =/109  Mark the database as "Store-Dependent" and record its P-lock Cached state (IS/IX) in the database in-memory structure110  Release the database "Store-Dependent" conversion lock(Part 2)151  Acquire the database dirty-page-list latch in X mode/=The latch is used to serialize                         =//=adding/deleting page to/from the                         =//=dirty-page-list             =/152  DO LOOP for each DIRTY page in the database dirty-page-list/=For each database, DBMS maintains                         =//=a list of dirty pages that have not                         =//=been externalized to disk or SES.                         =/153  Acquire a page latch in S mode to serialize updates against this dirty page/=The dirty-page-list latch is not                         =//=used to serialize updates against                         =//-pages that were already in the list.                         =//=Page latches are used to serialize                         =//=concurrent reads/updates for pages                         =//=that are cached in the buffer pool.                         =/154  Mark page in write I/O in progress mode/=Once a page is in this state, DBMS                         =//=suspends all subsequent updates                         =//=to this page until the disk write                         =//=I/O is completed155  Release the page latch/=Once a page is marked in write I/O                         =//=state, page latch is no longer                         =//=required to prevent subsequent                         =//=updates to this page        =/156  Dequeue this page from the dirty-page-list and add it to a local write-page-list/=To improve disk I/O efficiency,                         =//=page writes are batched     =/157  END158  Initiate disk write I/O to write all pages in the local write-page-list and wait until all I/Os are completed159  Write a "Database Conversion" log record and force it to the log data set to indicate the database is "Store-Dependent"/=this log record is used by DBMS to                         =//=determine whether or not the                         =//=database was "Store-Dependent" when                         =//=database-P locks are lost   =/160  Reflect the new P-lock Cache state and "Store-Dependent" attribute in the database in-memory structure/=Once the database is marked "Store-                         =//=Dependent" with the new P-lock                         =//=Cache state, all subsequent database                         =//=updates are required to observe                         =//="Force-At-Commit" policy as well                         =//=as determining whether to use                         =//=page P-locks to manage page =//=coherency                   =/160a Downgrade the database P lock to SIX/IX mode161  Release the database dirty-page-list latch/=Updates are now allowed against this                         =//=database except for those pages                         =//=which are still marked in write I/O                         =//-progress state              =/162  DO LOOP for each page in the local write-page-list163  Reset the page write I/O in progress state and mark the page as a CLEAN page164  Resume all transactions that need to update this page/=Once the update transaction is                         =//=resumed, it needs to reexamine                         =//=the page status and add page to                         =//=the dirty-page-list if it is not                         =//=DIRTY                       =/165  END.______________________________________
TABLE II______________________________________(Part 1)201  Acquire the database "Store-Dependent" conversion lock in X mode/=This lock is used to serialize                         =//="Store-Dependent" and "Non-Store-                         =//=Dependent" conversion for a database                         =/202  Acquire the database P-lock in X mode/=LLM/GLM triggers DBMS1 lock exit                         =//=(due to lock conflict) to release                         =//=the database-P lock. DBMS2 will                         =//=wait until DBMS1 has released the                         =//=database-P lock.            =/203  Write a "Database Open" log record and force it to the log data set to indicate the database is "Non-Store-Dependent"/=This log record is used by DBMS to                         =//=determine whether or not the                         =//=database was "Store-Dependent" when                         =//=database-P locks are lost.  =/204  Mark the database as "Non-Store-Dependent" and record its P-lock Cached state (X) in the database in-memory structure/=SS will not be used by this database                         =//=and DBMS applies "No-Force-At-Commit"                         =//=policy for updates against this                         =//=database                    =/205  Release the database "Store-Dependent" conversion lock(Part 2)251  IF the database-P lock was held in X mode THEN/=database was updated by DBMS1 and                         =//=potentially there are changed pages                         =//=still cached in DBMS1 local buffers                         =/252  DO253  DO LOOP for each DIRTY page in the database dirty-page-list/=for each database, DBMS maintains                         =//=a list of dirty pages that have not                         =//=been externalized to disk or SS                         =/254  Dequeue this page from the dirty-page-list and add it to a local write-page-list/=to improve disk I/O efficiency.                         =//=page writes are batched     =/255  END.156  Initiate disk write I/O to write all pages in the local write-page-list and wait until all I/O's are completed257   END.258  ELSE/=P-lock was held in S mode, database                         =//=was not updated by DBMS1    =/259  Scan buffer pool to purge all cached pages that belong to this database/=Once DBMS2 starts updating the                         =//=database, DBMS1 cached pages will                         =//=become down-level           =/260  Release the database-P lock/=once the P-lock is released, the                         =//=database cannot be accessed until                         =//=the database-P lock is reacquired                         =/______________________________________
TABLE III______________________________________(Part 1)301  Acquire the database "Store-Dependent" conversion lock in X mode/=this lock is used to serialize                         =//="Store-Dependent" and "Non-Store-                         =//=Dependent" conversion for a database                         =/302  Acquire the database P-lock in IX mode/=LLM/GLM triggers DBMS1 lock exit                         =//=(due to lock conflict) to downgrade                         =//=the database-P lock. DBMS2 will                         =//=wait until DBMS1 has downgraded the                         =//=database-P lock to IS mode  =/302a If RSOS = NULL change database P lock X302b If RSOS = IS change database P lock SIX303  Write a "Database Open" log record and force it to the log data set to indicate the database is "Store-Dependent"/=this log record is used by DBMS to                         =//=determine whether or not the                         =//=database was "Store-Dependent" when                         =//=database-P locks are lost   =/304  Mark the database as "Store-Dependent" and record its P-lock Cached state (SIX) in the database in-memory structure/=SS will be used by this database                         =//=and DBMS2 applies "Force-At-Commit"                         =//=for updates against this database                         =/305  Release the database "Store-Dependent" conversion lock(Part 2)351  Mark the database in-memory structure to indicate that the database is now "Store-Dependent" and the database P-lock state is IS/=with P-lock state held in IS,                         =//=database will continue to stay                         =//=in read only access mode    =/352  Downgrade the database P-lock from S to IS______________________________________
TABLE IV______________________________________401  Acquire the database-L lock (i.e., transaction lock) in S mode to quiesce and prevent transactions from updating this database402  DO LOOP for all the changed pages for this database in the SS403  Notify SS to retrieve the page names of the first/next set of changed page for this database/=SS provides a special protocol to                         =//-retrieve the names of all changed                         =//=pages in SS for a database. =//=Since the feedback name-area size is                         =//=limited, DBMS might have to invoke                         =//=SS multiple times to retrieve all                         =//=changed pages.              =/404  If no more changed pages THEN/=Either SS has no changed pages                         =//=for this database (first call) or                         =//=all changed pages have already                         =//=been castout by this process (next                         =//=call request)               =/405  GO TO T2L1/=all changed pages have already been                         =//=castout to disk             =/406  DO LOOP all changed page names retrieved from SS407  Notify SS to perform Read-For-Castout for page P/=Mark page P in SS as in castout                         =//=pending state and transfer  =//=data from SS to castout buffer                         =/408  Write page P to disk from the castout buffer409  Notify SS to perform Unlock-Castout-Lock/=Reset castout pending for page P                         =/410   END.411  END.412  T2L1:413  Notify SS to purge all the pages of this database from the SS/=SS should not cache any pages for                         =//=this database once the database is                         =//=converted to "Non-Store-Dependent"                         =/414  Write a "Database Conversion" log record to indicate the database is now "Non-Store-Dependent"/=this log record is used by DBMS to                         =//=determine whether or not the                         =//=database was "Store-Dependent" when                         =//=database-P locks are lost   =/415  IF it is ready to close the database THEN/=this process is triggered on behalf                         =//=of a database close request =/416  Close the database by purging pages from the local buffer pool and release the database-P lock417  ELSE/=it is triggered by the last updating                         =//=system to upgrade the database-P                         =//=lock Cached state to X      =/418  Change the database-P lock mode to X and set the database in-memory structure to indicate that it is "Non-Store-Dependent" and its cache state is "X"419  Release the database-L lock______________________________________
TABLE V______________________________________501  Query LLM/GLM for all "Store-Dependent" databases that are using the SS at time of failure/=DBMS ensures that the database-P                         =//=locks are held in SIX/IX mode for                         =//=all "Store-Dependent" databases                         =//=the database-P lock name also has                         =//=identifier which allows DBMS to                         =//=query database-P locks that are                         =//=associated with a given SS  =/502  Set "Recover Pending" for databases that are "Store-Dependent"/=once a database is marked recover                         =//=pending, it is unavailable until                         =//=it is recovered. Note that it is                         =//=a logical data recovery operation                         =//=and will only need to apply DBMS                         =//=logs against the current disk copy                         =//=of the database             =/______________________________________
1 * Research Report Aries: A Transaction Recovery Method Supporting Fine Granularity Locking and Partial Rollbacks Using Write Ahead Logging C. Mohan, pp. 1 58, Jan. 23, 1989.
2 * Research Report Recovery and Coherency Control Protocols for Fast Intersystem Page Transfer and Fine Granularity Locking in a Shared Disk Transaction Environment C. Mohan & Marang pp. 1 31, Mar. 15, 1991.
3 Research Report--"Aries: A Transaction Recovery Method Supporting Fine-Granularity Locking and Partial Rollbacks Using Write Ahead Logging" C. Mohan, pp. 1-58, Jan. 23, 1989.
4 Research Report--"Recovery and Coherency Control Protocols for Fast Intersystem Page Transfer and Fine Granularity Locking in a Shared Disk Transaction Environment" C. Mohan & Marang pp. 1-31, Mar. 15, 1991.
US6704767 * Mar 1, 2001 Mar 9, 2004 Oracle International Corporation Using distributed information about lock conversion requests to efficiently manage lock state transitions
US9342383 * Feb 29, 2008 May 17, 2016 Sap Se Streaming operations for workflow process models using multiple views on a same buffer
US9658864 * Aug 2, 2010 May 23, 2017 Samsung Electronics Co., Ltd Method and device for creation of integrated user interface
US20090172691 * Feb 29, 2008 Jul 2, 2009 Sap Ag Streaming operations for workflow process models
US20110041078 * Aug 2, 2010 Feb 17, 2011 Samsung Electronic Co., Ltd. Method and device for creation of integrated user interface
CN103814362A * Jul 20, 2012 May 21, 2014 国际商业机器公司 Transaction processing system, method and program
CN103814362B * Jul 20, 2012 Jun 15, 2016 国际商业机器公司 用于分布式kvs系统的处理方法和系统
U.S. Classification 1/1, 711/112, 711/152, 714/20, 714/E11.131, 707/E17.007, 707/999.008, 707/999.201, 707/999.202
Cooperative Classification G06F11/1471, G06F17/30362, Y10S707/99952, Y10S707/99938, Y10S707/99953
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST.;ASSIGNORS:JOSTEN, JEFFREY W.;MASATANI, TINA L.;MOHAN, CHANDRASEKARAN;AND OTHERS;REEL/FRAME:006139/0081;SIGNING DATES FROM 19920407 TO 19920410