Patent Grant
9734187
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
One or more implementations relate generally to atomic transactions in a NoSQL database.
The subject matter discussed in the background section should not be assumed to be prior art merely as a result of its mention in the background section. Similarly, a problem mentioned in the background section or associated with the subject matter of the background section should not be assumed to have been previously recognized in the prior art. The subject matter in the background section merely represents different approaches, which in and of themselves may also be inventions.
Some database systems may create errors due to offering concurrent access to multiple readers and writers. For a simple example used to illustrate concurrent access principles but not intended to describe real world practices, when a wife and a husband both access their joint checking account through different computers at the same time, their concurrent transactions may create errors. The wife's mobile phone and the husband's tablet computer each concurrently read their joint account balance as $1,000. When the wife's mobile phone processes her request to transfer $50 from a savings account to the joint checking account, the wife's mobile phone adds the $50 deposit to the previously read $1,000 balance to result in a new balance of $1,050, which the wife's mobile phone writes to the bank's database. When the husband's tablet computer processes his request to pay $50 electronically to a creditor, the husband's tablet computer subtracts the $50 payment from the previously read $1,000 balance to result in a new balance of $950, which the husband's tablet computer writes to the bank's database. Although the equal deposit and withdrawal of $50 should have resulted in the same balance of $1,000 that preceded these two transactions, the use of stale data in the second transaction resulted in a database system error.
Some database systems address such problems through pessimistic concurrency control, which temporarily locks subsequent access to a data item when the data item is initially accessed. For example, when the wife's mobile phone reads the data items for the joint checking account, the database system locks these data items, such that the access request made only one half second later by the husband's tablet computer is denied the access to read the joint checking account information. While this result may produce frustration for only the husband in this simplified example, database administrators of database systems with thousands of users may want to avoid using a locking algorithm that prevents read access for many users who may only be requesting to read data items. Consequently, pessimistic concurrency control can deliver poor performance because locking can drastically limit effective concurrency.
Therefore, some database system administrators use optimistic concurrency control, which assumes that multiple transactions can frequently complete without interfering with each other. Transactions access data items without acquiring locks on those data items. Before committing a write to a data item, a transaction verifies that no other transaction has modified the data item that the transaction is about to overwrite. If this verification reveals potentially conflicting modifications, the committing transaction rolls back and can be restarted. This safeguard for the data item is at the write cycle for optimistic concurrency control, which is much later in the transaction process than locking the data item at the read cycle for pessimistic concurrency control. Optimistic concurrency control is generally used in environments with low data contention. When conflicts are rare, transactions can complete without the expense of managing access locks and without having transactions wait for other transactions' access locks to clear, leading to higher throughput than pessimistic concurrency control. However, if contention for data items is frequent, the cost of repeatedly restarting transactions hurts performance significantly; such that pessimistic concurrency control may have better performance under these conditions.
In database systems with multiple readers and writers, there may be occasions when it is necessary to write multiple data items in an atomic fashion so that readers and writers do not have inconsistent views of underlying data. For example, the wife's mobile phone may request to pay $100 electronically from the joint checking account to an electric bill account on June 10th, which requires access to the three data items for the joint checking account balance, payee, and payment date. Continuing this example, the husband's tablet computer may request to pay $50 electronically from the joint checking account to a credit card bill account on June 20th, which requires access to the same three data items for the joint checking account balance, payee, and payment date.
For this example, a database system needs to allow atomic actions for all three of the data items, such that all three of the write requests from the wife's mobile phone are committed together and all three of the write requests from the husband's tablet computer are committed together. Committing only one write request from one computer for one data item and committing write requests out of order may risk the writing of inconsistent data. For example, committing only one of the multiple write requests for a transaction may result in paying the electric bill amount to the credit card account or paying the electric bill account late on the due date for the credit card bill. Some NoSQL database systems, such as HBase, currently allow atomic actions for a single row, thereby limiting the complexity of theses NoSQL database systems or forcing users to accept inconsistent data. Database system such as HBase store large quantities of sparse data.
In accordance with embodiments, there are provided systems and methods for atomic transactions in a NoSQL database. A system determines whether write claim data for a first data item in a NoSQL database includes a first previous transaction identifier included in last commit data for the first data item. For example, a database system determines whether the write claim data for a joint checking account balance includes the previous transaction identifier that is included in the last commit data for the joint checking account balance. The system writes a pending transaction identifier to the write claim data for the first data item in response to a determination that the write claim data for the first data item includes the first previous transaction identifier included in the last commit data for the first data item. For example, the database system writes the pending transaction identifier to the write claim data for the joint checking account balance because the write claim data for the joint checking account balance includes the previous transaction identifier that is included in the last commit data for the joint checking account balance.
The system writes the pending transaction identifier and a pending commit identifier to the last commit data for the first data item. For example, the database system writes the pending transaction identifier and the pending commit identifier to the last commit data for the joint checking account balance. The system writes a first value associated with a pending transaction to the first data item. For example, the database system writes a value to the joint checking account balance. The system aborts the pending transaction in response to a determination that the write claim data for the first data item does not include the first previous transaction identifier included in the last commit data for the first data item. For example, the database system aborts the pending transaction associated with the pending transaction identifier if the write claim data for the joint checking account balance does not include the previous transaction identifier that is included in the last commit data for the joint checking account balance. Accordingly, systems and methods are provided which enable a database system to provide atomic transactions in a NoSQL database.
While one or more implementations and techniques are described with reference to an embodiment in which atomic transactions in a NoSQL database is implemented in a system having an application server providing a front end for an on-demand database service capable of supporting multiple tenants, the one or more implementations and techniques are not limited to multi-tenant databases nor deployment on application servers. Embodiments may be practiced using other database architectures, i.e., ORACLE®, DB2® by IBM and the like without departing from the scope of the embodiments claimed.
Any of the above embodiments may be used alone or together with one another in any combination. The one or more implementations encompassed within this specification may also include embodiments that are only partially mentioned or alluded to or are not mentioned or alluded to at all in this brief summary or in the abstract. Although various embodiments may have been motivated by various deficiencies with the prior art, which may be discussed or alluded to in one or more places in the specification, the embodiments do not necessarily address any of these deficiencies. In other words, different embodiments may address different deficiencies that may be discussed in the specification. Some embodiments may only partially address some deficiencies or just one deficiency that may be discussed in the specification, and some embodiments may not address any of these deficiencies.
In the following drawings like reference numbers are used to refer to like elements. Although the following figures depict various examples, the one or more implementations are not limited to the examples depicted in the figures.
General Overview
Systems and methods are provided for atomic transactions in a NoSQL database.
As used herein, the term multi-tenant database system refers to those systems in which various elements of hardware and software of the database system may be shared by one or more customers. For example, a given application server may simultaneously process requests for a great number of customers, and a given database table may store rows for a potentially much greater number of customers. As used herein, the term query plan refers to a set of steps used to access information in a database system.
A NoSQL database provides a mechanism for storage and retrieval of data that is modeled in means other than the tabular relations used in relational databases. Motivations for this approach include simplicity of design, horizontal scaling and finer control over availability. The NoSQL data structure differs from the data structure for relational database management systems, and therefore some operations are faster in NoSQL and other operations are faster in relational database management systems. The particular suitability of a given NoSQL database depends on the problem to be solved. Barriers to the greater adoption of NoSQL databases in practice include the lack of full atomic transaction support. In an atomic transaction, a series of database operations all occur, or nothing occurs and any other access to the system (such as from another transaction) either sees all the updates or none of the updates—never partially. A guarantee of atomicity prevents updates to a database occurring only partially, which can cause greater problems than rejecting the whole series of database operations outright. In other words, atomicity means indivisibility and irreducibility.
The database system stores the values in the data table 100 based on transactions identified by the transaction identifiers T121, T122, and T123, which resulted in the writing of the values by commits identified by the commit identifiers 111, 112, and 113. For example, the joint checking account balance began with $1,000, and a wife's mobile phone initiated a transaction identified by the transaction identifier T121 to pay $100 electronically to an electric bill account on June 10th. The database system generated the commit identifier 111, wrote the value $900 to the data item 101 for the joint checking account balance, wrote the value June 10 to the data item 102 for the payment date, and wrote the value “Electric Bill” to the data item 103 for the payee, and also wrote the commit identifier 111 to the corresponding column for the data items 101-103.
Subsequently, a husband's tablet computer initiated a transaction identified by the transaction identifier T122 to pay $50 electronically to a credit card account on June 20th. The database system generated the commit identifier 112, wrote the value $850 to the data item 101 for the joint checking account balance, wrote the value June 20 to the data item 102 for the payment date, and wrote the value “Credit Card” to the data item 103 for the payee, and also wrote the commit identifier 112 to the corresponding column for the data items 101-103. The wife's mobile phone initiated a transaction identified by the transaction identifier T123 to transfer $1,000 electronically from a savings account to the joint checking account. The database system generated the commit identifier 113, and wrote the value $1,850 to the data item 101 for the joint checking account balance, and also wrote the commit identifier 113 to the corresponding column for the data item 101.
In block 202, a global commit identifier associated with a most recent fully committed transaction is optionally identified. For example and without limitation, this can include the database system processing a new transaction identified by the transaction identifier 124, described below in reference to
In block 204, a recent value is optionally read for a first data item by selecting a value for the first data item which corresponds to a highest sequential commit identifier that is less than or equal to a global commit identifier. By way of example and without limitation, this can include the database system processing the new transaction identified by the transaction identifier 124 by reading the most recent value for the data item 101, to which the new transaction is to write. The most recent value is read for an operation that uses the most recent value to create a new value, such as using an existing bank balance to create a new bank balance based on the existing bank balance and a new operation that affects the existing bank balance. The database system reads the most recent value for the data item 101 by selecting the value of $1,850 for the joint checking account balance which corresponds to the highest sequential commit identifier 113 that is less than or equal to the global commit identifier 113. This reading of data values may be for any number of data items—as many as the transactions read before the database system starts to commit transactions.
In another example, the database system processes the new transaction identified by the transaction identifier 124 by reading the most recent value for the data item 102 by selecting the value of June 20 for the payment date which corresponds to the highest sequential commit identifier 112 that is less than or equal to the global commit identifier 113, because the $1,000 deposit made by the commit identified by the commit identifier 113 did not result in writing any data to the data item 102.
In yet another example, even if the database system identifies a new value of “Water Bill” written by a commit identified by commit identifier 115, described below in reference to
The database system thereby provided the new transaction identified by the transaction identifier 124 with a consistent view of data that existed at a specific point in time rather than attempting to read any values written by a transaction that began after the beginning of the new transaction identified by the transaction identifier 124. The database system only attempts to read past or present values for a pending transaction, and not what are considered to be future values from the perspective of the pending transaction. Therefore, a user who initiated a transaction sees the database values as they were when the user's transactions began, and does not see any changes which subsequently occurred to the database due to any other transactions until after the user's transaction completes.
In block 206, a determination is made whether write claim data for a first data item in a NoSQL database includes a first previous transaction identifier included in last commit data for the first data item. In embodiments, this can include the database system processing the new transaction identified by the transaction identifier 124 by determining whether the write claim data for a joint checking account balance includes the previous transaction identifier 123 that is included in the last commit data for the joint checking account balance. If the database system determines that the write claim data for the first data item includes the first previous transaction identifier included in the last commit data for the first data item, then the method 200 continues to block 208 to continue processing for the pending transaction. Alternatively, if the database system determines that the write claim data for the first data item does not include the first previous transaction identifier included in the last commit data for the first data item, then the method 200 proceeds to block 224 to abort the pending transaction.
The determination in block 206 eliminates the problem of using stale data by verifying whether any other transaction has established a claim to write a value to the data item after the database system read the value of the data item for a pending transaction. The database system verifies whether any other transaction has established a claim to write a value to the data item by reading the write claim data for the data item and determining if another transaction other than the transaction identified by the global transaction identifier has written its transaction identifier to the write claim data for the data item. If no other transaction has established a claim to write to a data item, the database system writes a transaction identifier for the pending transaction to the write claim data for the data item. Writing the transaction identifier for the pending transaction to the write claim data for the data items establishes the pending transaction's claim to write a value to the data item. The database system repeats this process for each data item to which the pending transaction is to write. If the database system is able to establish the claim to write to every data item to which the pending transaction is to write, the pending transaction may be able to complete an atomic write. However, if the database system is unable to establish the claim to write to any of the data items to which the pending transaction is to write because the write claim data for any of the data items stores a transaction identifier other than a transaction identifier that is less than or equal to the global transaction identifier, then the database system aborts the pending transaction because the pending transaction cannot complete an atomic write. Establishing a claim to write establishes a transaction's claim to write to one data item, and if a transaction can establish a claim to write for all data items, the transaction may be able to complete an atomic write.
In block 208, a pending transaction identifier is written to write claim data for a first data item in response to a determination that the write claim data for the first data item includes a first previous transaction identifier included in last commit data for the first data item. For example and without limitation, this can include the database system processing the new transaction identified by the transaction identifier 124 by writing the pending transaction identifier 124 to the write claim data for the joint checking account balance because the write claim data for the joint checking account balance includes the previous transaction identifier 123 that is included in the last commit data for the joint checking account balance. In this example, the database system is able to establish a claim to write to a data item to which the pending transaction is to write.
In block 210, a determination is optionally made whether write claim data for a second data item in a NoSQL database includes a second previous transaction identifier included in last commit data for the second data item. By way of example and without limitation, this can include the database system determining whether the write claim data for the data item 103 for a payee includes the previous transaction identifier 122 that is included in the last commit data for the data item 103 for the payee. If the database system determines that the write claim data for the second data item includes the second previous transaction identifier included in the last commit data for the second data item, then the method 200 continues to block 212 to continue processing for the pending transaction. Alternatively, if the database system determines that the write claim data for the second data item does not include the second previous transaction identifier included in the last commit data for the second data item, then the method 200 proceeds to block 224 to abort the pending transaction.
Block 210 applies to the second data item, whereas block 206 applies to the first data item, as the database system must check the write claim data for each data item to which the pending transaction is to write to insure an atomic transaction. The determination in block 210 eliminates the problem of using stale data by verifying whether any other transaction has established a claim to write a value to the data item after the database system read the value of the data item for the pending transaction. The database system verifies whether any other transaction has established a claim to write a value to the data item by reading the write claim data for the data item and determining if another transaction other than the transaction identified by the global transaction identifier has written its transaction identifier to the write claim data for the data item. If no other transaction has established a claim to write to a data item, the database system writes a transaction identifier for the pending transaction to the write claim data for the data item. Writing the transaction identifier for the pending transaction to the write claim data for the data items establishes the pending transaction's claim to write a value to the data item. The database system repeats this process for each data item to which the pending transaction is to write. If the database system is able to establish the claim to write to every data item to which the pending transaction is to write, the pending transaction may be able to complete an atomic write. However, if the database system in unable to establish the claim to write to any of the data items to which the pending transaction is to write, then the database system aborts the pending transaction because the pending transaction cannot complete an atomic write.
In block 212, a pending transaction identifier is optionally written to write claim data for a second data item in response to a determination that the write claim data for the second data item includes a second previous transaction identifier included in last commit data for the second data item. In embodiments, this can include the database system writing the pending transaction identifier 124 to the write claim data for the data item 103 for the payee because the write claim data for the data item 103 for the payee includes the previous transaction identifier 122 that is included in the last commit data for the data item 103 for the payee. In this example, the database system is able to establish a claim to write to another data item to which the pending transaction is to write. Although method 200 is a simplified example of two determinations of whether another transaction has a claim to write to two corresponding data items and establishing the claims to write to the data items, the method 200 may include any number of determinations for any number of corresponding data items and establishing any number of claims to write to the data items. The method 200 continues to block 214 only if the database system can establish claims to write to all of a pending transaction's data items. If the database system cannot establish claims to write to all of the pending transaction's data items, then the database system aborts the pending transaction.
In block 214, a pending transaction identifier and a pending commit identifier are written to last commit data for a first data item. For example and without limitation, this can include the database system generating a pending commit identifier 114, described below if reference to
In block 216, a first value associated with a pending transaction is written to a first data item. By way of example and without limitation, this can include the database system writing the value $1,700 to the joint checking account balance based on the previous balance of $1,850 and a new electronic payment of $150 for the electric bill, information which had been stored in a write log for the pending transaction. A simplified example of data stored in such a write log may be: data item 101=$1750, data item 102=July 10, data item 103=electric bill.
In block 218, a pending transaction identifier and a pending commit identifier are written to last commit data for a second data item. In embodiments, this can include the database system writing the pending transaction identifier 124 and the pending commit identifier 114 to the last commit data for the data item 103 for the payee. The database system records the necessary identifiers in the last commit data for a data item that is about to be overwritten with a new value, thereby enabling subsequent transactions to repeat the process of method 200 and identify the new value written to the data item.
In block 220, a second value associated with a pending transaction is written to a second data item. For example and without limitation, this can include the database system writing the value “Electric Bill” to the data item 103 for the payee, information which had been stored in the write log for the pending transaction.
In block 222, a global commit identifier is optionally equated to a pending commit identifier. By way of example and without limitation, this can include the database system equating the global commit identifier to the pending commit identifier 114, and then the method 200 stops. The database system records the pending transaction's commit identifier as the updated global commit identifier in the specific global commit identifier storage, thereby enabling subsequent transactions to repeat the process of method 200 and identify any new values written to the corresponding data items. The database system has written the transaction values atomically to the corresponding data items, even though the data items are stored in a NoSQL database. At this point the pending transaction has finished. Assuming that global commit identifiers increase, the global commit identifier is the highest numbered pending transaction identifier for which all lower numbered transactions have finished. For example, given transaction identifiers 1, 2, 3, and 4, where transactions 1, 2, and 4 have finished, the global commit identifier is 2 until transaction 3 finishes, in which case the global commit identifiers becomes 4.
In block 224, a pending transaction is aborted in response to a determination that write claim data for a data item does not include a first previous transaction identifier included in last commit data for the data item. In embodiments, this can include the database system aborting the transaction associated with the pending transaction identifier 124 if either the write claim data for the joint checking account balance does not include the previous transaction identifier 123 or the data item 103 for the payee does not include the previous transaction 122, which is included in the last commit data for the joint checking account balance or the data item 103 for the payee. If the database system cannot establish claims to write to all of the pending transaction's data items, then the database system aborts the pending transaction, and uses the write log for the pending transaction to roll back the transaction identifiers in the write claim data for the pending transaction's data items. The database system uses the write log to identify the pending transaction's data items, and then writes the previous transaction identifiers in the write claim data for the pending transaction's data items. The database system may retrieve the previous transaction identifiers from the last commit data for the pending transaction's data items.
The method 200 may be repeated as desired. Although this disclosure describes the blocks 202-224 executing in a particular order, the blocks 202-224 may be executed in a different order. In other implementations, each of the blocks 202-224 may also be executed in combination with other blocks and/or some blocks may be divided into a different set of blocks. Accordingly, systems and methods are provided which enable a database system to provide atomic transactions in a NoSQL database.
The method 200 enables the database system to avoid using stale data and to process the transactions T 124 and T125 atomically and concurrently. If two concurrent transactions attempt to write to the same data item, the transactions will not deadlock, which is a problem for pessimistic concurrency control, because either one transaction can succeed before the database system aborts the other transaction or the database system may abort both transactions before either transaction succeeds.
Additionally, the database system may flush values that are unlikely to be read again, thereby providing additional storage capacity. For example, if the database system is limited to storing only three values for each of the data items 101, 102, and 103, the database system may purge the values associated with the commit identifiers 111 and 112 because none of these values is the most current value for any of the data items 101, 102, or 103, as depicted in
While one or more implementations have been described by way of example and in terms of the specific embodiments, it is to be understood that one or more implementations are not limited to the disclosed embodiments. To the contrary, it is intended to cover various modifications and similar arrangements as would be apparent to those skilled in the art. Therefore, the scope of the appended claims should be accorded the broadest interpretation so as to encompass all such modifications and similar arrangements.
This application claims the benefit of U.S. Provisional Patent Application 61/807,874 entitled SYSTEM AND METHOD FOR LOCK-FREE OPTIMISTIC ATOMIC TRANSACTIONS, by Fuchs, filed Apr. 3, 2013, the entire contents of which is incorporated herein by reference.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5577188 | Zhu | Nov 1996 | A |
| 5608872 | Schwartz | Mar 1997 | A |
| 5649104 | Carleton | Jul 1997 | A |
| 5715450 | Ambrose et al. | Feb 1998 | A |
| 5761419 | Schwartz | Jun 1998 | A |
| 5819038 | Carleton | Oct 1998 | A |
| 5821937 | Tonelli et al. | Oct 1998 | A |
| 5831610 | Tonelli et al. | Nov 1998 | A |
| 5873096 | Lim et al. | Feb 1999 | A |
| 5918159 | Fomukong et al. | Jun 1999 | A |
| 5963953 | Cram et al. | Oct 1999 | A |
| 6092083 | Brodersen et al. | Jul 2000 | A |
| 6161149 | Achacoso et al. | Dec 2000 | A |
| 6169534 | Raffel et al. | Jan 2001 | B1 |
| 6178425 | Brodersen et al. | Jan 2001 | B1 |
| 6189011 | Lim et al. | Feb 2001 | B1 |
| 6216135 | Brodersen et al. | Apr 2001 | B1 |
| 6233617 | Rothwein et al. | May 2001 | B1 |
| 6266669 | Brodersen et al. | Jul 2001 | B1 |
| 6295530 | Ritchie et al. | Sep 2001 | B1 |
| 6324568 | Diec | Nov 2001 | B1 |
| 6324693 | Brodersen et al. | Nov 2001 | B1 |
| 6336137 | Lee et al. | Jan 2002 | B1 |
| D454139 | Feldcamp | Mar 2002 | S |
| 6367077 | Brodersen et al. | Apr 2002 | B1 |
| 6393605 | Loomans | May 2002 | B1 |
| 6405220 | Brodersen et al. | Jun 2002 | B1 |
| 6434550 | Warner et al. | Aug 2002 | B1 |
| 6446089 | Brodersen et al. | Sep 2002 | B1 |
| 6535909 | Rust | Mar 2003 | B1 |
| 6549908 | Loomans | Apr 2003 | B1 |
| 6553563 | Ambrose et al. | Apr 2003 | B2 |
| 6560461 | Fomukong et al. | May 2003 | B1 |
| 6574635 | Stauber et al. | Jun 2003 | B2 |
| 6577726 | Huang et al. | Jun 2003 | B1 |
| 6601087 | Zhu | Jul 2003 | B1 |
| 6604117 | Lim et al. | Aug 2003 | B2 |
| 6604128 | Diec | Aug 2003 | B2 |
| 6609150 | Lee et al. | Aug 2003 | B2 |
| 6621834 | Scherpbier | Sep 2003 | B1 |
| 6654032 | Zhu | Nov 2003 | B1 |
| 6665648 | Brodersen et al. | Dec 2003 | B2 |
| 6665655 | Warner et al. | Dec 2003 | B1 |
| 6684438 | Brodersen et al. | Feb 2004 | B2 |
| 6711565 | Subramaniam et al. | Mar 2004 | B1 |
| 6724399 | Katchour et al. | Apr 2004 | B1 |
| 6728702 | Subramaniam et al. | Apr 2004 | B1 |
| 6728960 | Loomans | Apr 2004 | B1 |
| 6732095 | Warshavsky et al. | May 2004 | B1 |
| 6732100 | Brodersen et al. | May 2004 | B1 |
| 6732111 | Brodersen et al. | May 2004 | B2 |
| 6754681 | Brodersen et al. | Jun 2004 | B2 |
| 6763351 | Subramaniam et al. | Jul 2004 | B1 |
| 6763501 | Zhu | Jul 2004 | B1 |
| 6768904 | Kim | Jul 2004 | B2 |
| 6772229 | Achacoso et al. | Aug 2004 | B1 |
| 6782383 | Subramaniam et al. | Aug 2004 | B2 |
| 6804330 | Jones et al. | Oct 2004 | B1 |
| 6826565 | Ritchie et al. | Nov 2004 | B2 |
| 6826582 | Chatterjee et al. | Nov 2004 | B1 |
| 6826745 | Coker | Nov 2004 | B2 |
| 6829655 | Huang et al. | Dec 2004 | B1 |
| 6842748 | Warner et al. | Jan 2005 | B1 |
| 6850895 | Brodersen et al. | Feb 2005 | B2 |
| 6850949 | Warner et al. | Feb 2005 | B2 |
| 7062502 | Kesler | Jun 2006 | B1 |
| 7340411 | Cook | Mar 2008 | B2 |
| 7356482 | Frankland et al. | Apr 2008 | B2 |
| 7401094 | Kesler | Jul 2008 | B1 |
| 7620655 | Larsson | Nov 2009 | B2 |
| 7698160 | Beaven et al. | Apr 2010 | B2 |
| 8010663 | Firminger et al. | Aug 2011 | B2 |
| 8015495 | Achacoso et al. | Sep 2011 | B2 |
| 8082301 | Ahlgren et al. | Dec 2011 | B2 |
| 8095413 | Beaven et al. | Jan 2012 | B1 |
| 8095594 | Beaven et al. | Jan 2012 | B2 |
| 8275836 | Beaven et al. | Sep 2012 | B2 |
| 8484111 | Frankland et al. | Jul 2013 | B2 |
| 8984170 | Colrain | Mar 2015 | B2 |
| 20010044791 | Richter et al. | Nov 2001 | A1 |
| 20020072951 | Lee et al. | Jun 2002 | A1 |
| 20020082892 | Raffel | Jun 2002 | A1 |
| 20020129352 | Brodersen et al. | Sep 2002 | A1 |
| 20020140731 | Subramaniam et al. | Oct 2002 | A1 |
| 20020143997 | Huang et al. | Oct 2002 | A1 |
| 20020162090 | Parnell et al. | Oct 2002 | A1 |
| 20020165742 | Robins | Nov 2002 | A1 |
| 20030004971 | Gong | Jan 2003 | A1 |
| 20030018705 | Chen et al. | Jan 2003 | A1 |
| 20030018830 | Chen et al. | Jan 2003 | A1 |
| 20030066031 | Laane et al. | Apr 2003 | A1 |
| 20030066032 | Ramachandran et al. | Apr 2003 | A1 |
| 20030069936 | Warner et al. | Apr 2003 | A1 |
| 20030070000 | Coker et al. | Apr 2003 | A1 |
| 20030070004 | Mukundan et al. | Apr 2003 | A1 |
| 20030070005 | Mukundan et al. | Apr 2003 | A1 |
| 20030074418 | Coker et al. | Apr 2003 | A1 |
| 20030120675 | Stauber et al. | Jun 2003 | A1 |
| 20030151633 | George et al. | Aug 2003 | A1 |
| 20030159136 | Huang et al. | Aug 2003 | A1 |
| 20030187921 | Diec et al. | Oct 2003 | A1 |
| 20030189600 | Gune et al. | Oct 2003 | A1 |
| 20030204427 | Gune et al. | Oct 2003 | A1 |
| 20030206192 | Chen et al. | Nov 2003 | A1 |
| 20040001092 | Rothwein et al. | Jan 2004 | A1 |
| 20040015981 | Coker et al. | Jan 2004 | A1 |
| 20040027388 | Berg et al. | Feb 2004 | A1 |
| 20040128001 | Levin et al. | Jul 2004 | A1 |
| 20040186860 | Lee et al. | Sep 2004 | A1 |
| 20040193510 | Catahan, Jr. et al. | Sep 2004 | A1 |
| 20040199489 | Barnes-Leon et al. | Oct 2004 | A1 |
| 20040199536 | Barnes Leon et al. | Oct 2004 | A1 |
| 20040249854 | Barnes-Leon et al. | Dec 2004 | A1 |
| 20040260534 | Pak et al. | Dec 2004 | A1 |
| 20040260659 | Chan et al. | Dec 2004 | A1 |
| 20040268299 | Lei et al. | Dec 2004 | A1 |
| 20050050555 | Exley et al. | Mar 2005 | A1 |
| 20050091098 | Brodersen et al. | Apr 2005 | A1 |
| 20090063415 | Chatfield et al. | Mar 2009 | A1 |
| 20100114830 | Vanhove | May 2010 | A1 |
| 20110153566 | Larson | Jun 2011 | A1 |
| 20120167098 | Lee | Jun 2012 | A1 |
| 20130024484 | Banerjee | Jan 2013 | A1 |
| 20140279987 | Chico de Guzman Huerta | Sep 2014 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 20140304245 A1 | Oct 2014 | US |
| Number | Date | Country | |
|---|---|---|---|
| 61807874 | Apr 2013 | US |
