US20060271510A1 - Database Caching and Invalidation using Database Provided Facilities for Query Dependency Analysis - Google Patents

Database Caching and Invalidation using Database Provided Facilities for Query Dependency Analysis Download PDF

Info

Publication number
US20060271510A1
US20060271510A1 US11/420,451 US42045106A US2006271510A1 US 20060271510 A1 US20060271510 A1 US 20060271510A1 US 42045106 A US42045106 A US 42045106A US 2006271510 A1 US2006271510 A1 US 2006271510A1
Authority
US
United States
Prior art keywords
database
query
results
caching
intermediary
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US11/420,451
Inventor
Nathaniel Harward
Andrew Geweke
Alexander Voskoboynik
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Terracotta Inc
Original Assignee
Terracotta Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Terracotta Inc filed Critical Terracotta Inc
Priority to US11/420,451 priority Critical patent/US20060271510A1/en
Publication of US20060271510A1 publication Critical patent/US20060271510A1/en
Assigned to TERRACOTTA, INC. reassignment TERRACOTTA, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: GEWEKE, ANDREW R, HARWARD, NATHANIEL D, VOSKOBOYNIK, ALEXANDER
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21Design, administration or maintenance of databases
    • G06F16/217Database tuning
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • G06F16/2455Query execution
    • G06F16/24552Database cache management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/52Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/52Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • G06F9/526Mutual exclusion algorithms
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/544Buffers; Shared memory; Pipes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1479Generic software techniques for error detection or fault masking
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16Error detection or correction of the data by redundancy in hardware
    • G06F11/20Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023Failover techniques
    • G06F11/203Failover techniques using migration
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00Indexing scheme relating to G06F9/00
    • G06F2209/52Indexing scheme relating to G06F9/52
    • G06F2209/522Manager
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/445Program loading or initiating

Definitions

  • the present invention relates generally to databases and caching systems for databases.
  • Databases are an integral part of many operations, businesses and organizations where access to structured data is needed. Databases offer manageability for the vast amounts of data that many of today's large scale enterprises rely upon in day to day operations. Through the use of database storage, seemingly incomprehensible amounts of data can be maintained in a structured environment so that requesting users can easily locate and retrieve needed information. Many of today's large-scale applications such as e-commerce, banking, etc. are able to present end-users with seemingly instant access to personalized information by using databases. Without database storage in many of these environments, the task of methodically sorting through the amount of information necessary to access that which is needed would likely frustrate the ultimate purpose of the application to the point of ending many operations.
  • Databases can be implemented in many languages and may support many protocols such as Structured Query Language (SQL) which provides users and applications the ability to interface with the database through SQL statements to select, insert, update, and delete information in the database.
  • SQL Structured Query Language
  • SQL statements can be combined to provide a high level of logic and interaction with data in a database.
  • Database caching techniques have been developed to decrease the amount of aggregate traffic transmitted between the database and requesting client devices. By caching database information in smaller faster memories, performance can be increased. Certain access requests will be satisfied from local cached versions of the database. This will not only increase the performance as seen by requesting applications or entities, but also decrease the amount of load placed on the database.
  • An inherent difficulty with database caching is the structured nature of both the data storage and retrieval.
  • traditional data caching scenarios such as caching recently accessed data from a large memory volume that is indexed according to a physical or logical address
  • discrete data segments can be cached in a smaller memory and referenced according to their location on the large memory volume.
  • the cache simply looks for an update to the location on the memory volume corresponding to the cached data and when the data at that location changes, the cache can simply invalidate or discard its cached results.
  • data is retrieved by passing queries such as SQL statements. These statements can access, combine, and manipulate data from different locations to satisfy the query request.
  • database caches relying on these traditional caching techniques are required to store a subset of an entire database's data structures. Data is cached based on memory locations and entries invalidated based on updates to those memory locations. These systems do not cache results based on an actual query. Because queries may combine or access data from various locations in the database, and request data based on logic that is dependent upon the data stored therein, it is difficult to accurately determine when the previously retrieved results for a query are no longer valid because of changes to data in the database. Complex analysis to parse a received query is thus required to determine what the query does at the database. While in theory such a technique is useful, in practice it presents obstacles.
  • Databases are typically written in a proprietary format and the underlying source code is not made available to those wishing to implement a caching system. Because an intimate knowledge of the database's internal operations and code can not be had, parsing the queries is in many instances deficient or even wrong. Moreover, individual database providers frequently alter their databases, requiring these parsing techniques to continually be updated as the database is updated.
  • schedule or time-based caching has been used for databases to overcome the difficulty with parsing queries. Entries in a cache are made for particular queries and the results of those queries. However, the entries are automatically invalidated after a specified amount of time without any regard to actual changes at the database. If changes to the database are made between invalidation periods and a request is received, the cache may return invalid results. Additionally, this technique can degrade performance and efficiency by needlessly invalidating accurate query results.
  • a database caching system and related techniques are provided that can reliably maintain and invalidate database data based on actual changes to data in the database. Updates or changes to data at the database are detected without parsing queries submitted to the database.
  • the dependencies of a received query can be determined by submitting a version of the received query to the database through a native facility provided by the database itself to analyze how query structures are processed at the database.
  • the caching system can access the results of the facility to determine the tables or rows (or other data partition) a received query is dependent upon or modifies.
  • an abstracted form of the query can be cached with an indication of the tables, rows, etc. that queries of that structure access or modify.
  • the tables a write or update query modifies can be cached with a time of their last modification.
  • the system can readily determine dependency information for the query, the last time the dependencies were modified, and compare this time with the time indicated for when the cached results were retrieved.
  • updates to the database can be detected.
  • a component is implemented at or on the system of the database to directly detect changes to the database data. This component can monitor transactional information maintained by the database itself to determine when changes to the database occur. This component can communicate with the cache to provide notification of changes to the database.
  • a method of caching database query results includes receiving a request for information from a database and determining if previously received results for the request are maintained locally. If previously received results are not maintained locally for the request, the method can include passing a form of the request to the database by calling a native analysis facility at the database to assess how the database processes requests of the form, accessing results of the assessment by the native analysis facility, determining from the results one or more dependencies of the database for requests of the form, maintaining data indicating that requests of the form for the database include the one or more dependencies, passing the request to the database and receiving results, and maintaining information including the request and the results of the request.
  • a database caching system includes a database including a native analysis facility to analyze query structures and a caching intermediary in communication with the database and an application accessing the database.
  • the caching intermediary maintains one or more queries and results received from the database in response to the one or more queries.
  • the caching intermediary receives a first query from the application and determines if the first query and previously received results for the first query are maintained by the caching intermediary.
  • the caching intermediary passes a form of the first query to the native analysis facility at the database if the caching intermediary is not maintaining results for the first query and accesses results of the analysis facility to determine one or more tables of the database upon which queries of the form depend.
  • the caching intermediary further maintains the form of the first query and an indication of the one of more tables of the database upon which queries of the form depend.
  • FIG. 1 is a block diagram of a database caching system in accordance with one embodiment.
  • FIG. 2 depicts a database cache in accordance with one embodiment.
  • FIG. 3 is a block diagram of a database caching system in accordance with one embodiment, wherein processing and caching database queries is depicted.
  • FIG. 4 is a flowchart for processing and caching database queries in accordance with one embodiment.
  • FIG. 5 is a block diagram of a database caching system in accordance with one embodiment, wherein the detection of a backend update to the database, and subsequent update to the cache is depicted.
  • FIG. 6 is a flowchart for detecting updates to a database and updating a database cache according to the update in accordance with one embodiment.
  • FIG. 7 is a flowchart for monitoring updates to a database using a listener component implemented as a debugger for at least a portion of the database.
  • FIG. 8 is a block diagram of a database caching system in accordance with one embodiment, wherein processing and caching of database stored procedures is depicted.
  • FIG. 9 is a flowchart for processing and caching database stored procedures in accordance with one embodiment.
  • FIG. 10 is a flowchart for caching database queries and invalidating the results of the database queries based on row level updates to the database.
  • FIG. 11 is a block diagram of a multi-level database caching system in accordance with one embodiment.
  • FIG. 1 is a block diagram depicting one embodiment of the technology described herein executing in an application server—database server environment.
  • FIG. 1 depicts an application server 102 and database server 122 .
  • a variety of applications 104 can be hosted and executed upon application server 102 .
  • Applications 104 can be implemented in any suitable language, including but not limited to the JavaTM programming language, C++, etc.
  • the application servers on which applications 104 are executed will vary by embodiment, but can support such platforms as the JavaTM 2 Platform, Enterprise Edition (J2EE) Platform.
  • J2EE JavaTM 2 Platform, Enterprise Edition
  • servers, processing systems, and other processor based devices as described can include, by way of non-limiting example, one or more processors capable of executing instructions provided on processor-readable media to perform the methods and tasks described herein.
  • the processing system may include a volatile memory, a mass storage device or other non-volatile memory, a portable storage device, one or more communications or network interfaces and various I/O devices.
  • a processing system hardware architecture as described is just one suitable example of a processing system suitable for implementing the present technology. While embodiments are presented with respect to exemplary server-based implementations, variations for stand-alone, client, and other suitable processing environments can be made without departing from the scope of the present disclosure.
  • the database server 122 hosts a database application 120 .
  • Database server 122 includes an operating system 124 and a non-volatile storage device 126 (such as a disk drive or RAID array).
  • a non-volatile storage device 126 such as a disk drive or RAID array.
  • Numerous types of databases 120 can be used in accordance with embodiments of the disclosed technology.
  • database 120 can include a database provided by OracleTM Corporation of Sunnyvale, Calif., a database provided by SybaseTM Corporation of Dublin, Calif., or a database provided by MicrosoftTM Corporation of Redmond, Wash.
  • the technology described herein is not limited to any particular type of database application. References to particular types and brands of databases and the particular functions of a type of database are presented for exemplary purposes and are not intended to limit the scope of the present disclosure or claimed subject matter.
  • Interface 106 is provided at application server 102 to enable applications 104 access to database 120 .
  • Interface 106 will vary by implementation according to the type of programming platform and/or database provided.
  • Interface 106 is provided in accordance with an Application Programming Interface (API) that provides connectivity between the programming language(s) and platforms associated with applications 104 and database 120 .
  • API Application Programming Interface
  • interface 106 is implemented in accordance with the JavaTM Database Connectivity (JDBC) API, an industry standard interface that provides database independent connectivity between the JavaTM programming language and a wide range of databases.
  • JDBC JavaTM Database Connectivity
  • Interface 106 is a JDBC driver in one embodiment, implementing the JDBC API to provide a call level API for SQL-based database access.
  • the JDBC driver can provide transparent access for applications 104 to database 120 .
  • a database caching intermediary 108 is provided at application server 102 to increase the performance, reliability and availability of the information maintained by database 120 for requesting applications 104 .
  • Cache 108 can provide previously received results for queries or other requests/calls submitted to database 120 that are maintained locally at application server 102 to increase the performance and availability of database 120 while decreasing the response time for requests.
  • Applications 104 request data from database 120 by submitting queries or other calls.
  • applications can submit commands formatted in accordance with the specifications of interface 106 (e.g., as JDBC commands) to provide SQL commands to database 120 .
  • Intermediary 108 can more quickly provide the results of a query if valid results are currently stored in the cache.
  • intermediary 108 can increase database availability by providing cached results when database 120 is inaccessible.
  • caching intermediary 108 includes an intermediary interface or driver 112 and a cache 110 .
  • Interface 112 can provide and execute many of the disclosed operations while cache 110 maintains portions of the data from database 120 and internal data used by the caching intermediary 108 that can maintain portions of database 120 in local memory.
  • Interface 112 conceptually wraps itself around native interface 106 to provide transparent intermediation between applications 104 and database 120 .
  • Applications 104 can communicate with interface 112 in the same manner they would with the native database interface. To requesting applications 104 , interface 112 will appear the same as the native interface 106 .
  • the intermediary interface forces applications 104 to communicate with the intermediary, instead of directly accessing interface 106 .
  • interface 112 is a HA-JDBC High Availability JavaTM Database Connectivity (HA-JDBC) driver.
  • Interface 112 will appear as a standard JDBC driver and thus provide a transparent solution to applications 104 for caching query results.
  • Intermediary 108 can be installed and integrated into an existing system without modifying any application source or object code and without modifying any database source or object code.
  • Applications 104 continue to access database 120 in the typical manner, appearing to interface directly with the native database driver 106 , while in fact, interfacing with the intermediary driver 112 provided in accordance with one embodiment.
  • Caching intermediary 108 provides cached results that are maintained current and invalidated where appropriate based on updates to database 120 or events processed by database 120 .
  • Changed data within the database is the impetus for determining that cached database results are no longer valid.
  • traditional schedule-based caches invalidate cached results based on a set schedule or time interval. Entries stored in the cache expire or are invalidated periodically based solely on an elapsed period of time. Invalidations occur in response to the mere passage of time without regard to any actual changes at the database. By using such a technique, these systems stand not only to return invalid data to requesting applications, but also to needlessly invalidate valid cached data and decrease performance.
  • Intermediary 108 can detect actual changes to database 120 and invalidate and/or update entries in cache 110 based on these updates rather than an elapsed period of time according to a predetermined schedule.
  • changes to database 120 are detected through queries submitted by applications 104 and received at the caching intermediary.
  • caching intermediary 108 is able to detect changes to database 120 made in response to queries without parsing the submitted queries.
  • the caching intermediary 108 calls a native analysis facility provided by and inherent to the database to analyze queries received from requesting applications. The analysis facility provides information regarding how a query submitted for analysis is processed by the database. Caching intermediary 108 can determine details of how the database processes the query, including the tables or other data partitions the database accesses to fulfill the requests.
  • caching intermediary 108 is a native facility or process provided by the database. This enables the intermediary to determine which tables of a database are accessed in responding to a query. Importantly, the intermediary is able to determine this information without parsing the actual query.
  • Databases typically provide debugging and performance analysis facilities as native database procedures available to end-users. These facilities are traditionally used by database administrators to debug queries or to increase the performance associated with a particular query. An administrator may view how a query is processed and modify the query structure based on this review to maximize performance.
  • Caching intermediary 108 can exploit one or more of these native facilities to determine the dependencies of queries it receives.
  • intermediary 108 may call an “EXPLAIN PLAN” facility to determine the dependencies of a query submitted to an OracleTM database. An abstracted or skeleton version of the query can be issued in a call to this facility to determine how such a query is processed and this, the tables accessed.
  • EXPLAIN PLAN an abstracted or skeleton version of the query
  • Numerous types of native database facilities may be used in various embodiments depending on the type of database platform, programming language, or server platform.
  • FIG. 2 depicts an exemplary implementation of intermediary cache 110 in accordance with one embodiment.
  • cache 110 includes three individual tables to facilitate caching and cache invalidation.
  • a results table 204 maintains a list 210 of queries and the results 212 of those queries as retrieved from the database.
  • Table 204 further includes an indication 214 of the time at which the query was processed and the results obtained from the database. In one embodiment, the results are time-stamped and the third column is not used.
  • Dependency table 206 maintains a list of query structures, also referred to as skeletons or footprints, along with a list of the tables from database 120 upon which queries of that structure are dependent.
  • a query skeleton is a form of an actual query without any variable data or literal expressions.
  • Literal expressions refer to the individual variables within a query for which input data is passed to the database to retrieve unique records. For example, a simple query (shown as entry 216 in table 204 ) that selects a record from an employee table where the user_id column is 12 will have a skeleton as shown by entry 222 in table 206 .
  • the skeleton shown is a form of the original query with the user_id literal expression “ 12 ” replaced with “:v.” All queries having the same skeleton will be processed in a similar manner and retrieve results from the same tables in the database. Any query having the structure of entry 222 is dependent upon the employee table. Replacing the literal expressions with “:v” is but one example of abstracting a query. Any suitable place holder can be used and in one embodiment, the literal sections are simply “marked off” using some external method (e.g., recording the indices of the start and end characters of each literal section).
  • Modification table 208 tracks modifications or updates to the tables in database 120 . Table 208 lists table from database 102 and the time at which the table was last updated.
  • the caching intermediary can determine if valid results are cached for a particular query. If results are listed in table 204 for a received query, table 206 is accessed to determine what tables the query is dependent upon. Table 208 is then accessed to determine when those tables were last modified. If the time of the last modification is before the time the results were obtained (table 204 ), the results are determined to be valid.
  • a listener component 128 is also provided to detect changes to data maintained by database 120 . This component provides the additional benefit of being able to detect so-called backend updates to database 120 that do not pass through intermediary 108 .
  • database 120 can be modified by a database administrator or other entity not in communication with intermediary 108 .
  • Listener component 128 can interface directly with the database at the database server to detect any backdoor updates that originate from beyond the reach or control of the caching intermediary.
  • invalidations of cached database results are based on actual changes to database data. Updates to the database trigger the invalidation of cache entries within a caching intermediary. A more efficient cache is provided by avoiding unnecessary invalidations of cached results, as inherent in time-based caches. Furthermore, invalidations based on changed data as determined from the database provides consistency between data in the cache and data in the cache and database. Moreover, the reliance on the database to analyze queries and determine dependency information avoids the limitations associated with parsing queries submitted to a database for which the underlying code and operation is not well understood.
  • FIG. 3 is a simplified block diagram depicting the communication flow of a database caching system in accordance with one embodiment.
  • Application 104 e.g., Application A
  • application server 102 communicates with caching intermediary 108 to access database 120 , implemented at database server 122 .
  • Application 104 issues query 140 for execution by database 120 .
  • Query 140 is received at caching intermediary 108 .
  • the interface 112 accesses intermediary cache 110 to determine if the intermediary is maintaining valid results for query 140 , retrieved from the database in response to a previous request including query 140 .
  • Interface 112 accesses cache 110 as indicated at 141 and determines whether results for query 140 are currently maintained locally at the cache. If the results are currently stored—in results table 204 for example—the intermediary accesses a dependency table 206 at cache 110 to determine which tables at the database queries of the received query's structure are dependent upon. Table 208 is then accessed to determine the last time each table query 140 is dependent upon was last updated. The time the results stored in results table 204 were obtained is compared with the last time each dependent table was updated to determine whether the cached results were retrieved from the database after the last update to any dependent table of the query. If the results were retrieved after the last update the cached results are returned as indicated at 138 .
  • Interface 112 abstracts the query by removing the literal expressions from the query string to create a query skeleton 142 having the structure of query 140 . After abstracting the query, intermediary interface 112 passes the skeleton 142 to the native database interface which forwards it to database 120 . In one embodiment, interface 112 checks cache 110 first to determine if the dependency analysis information for the abstracted query is already stored. If so, the abstracted query is not passed.
  • interface 112 passes query structure 142 by calling a native analysis or tuning facility 162 provided by database 120 .
  • native indicates that the facility or process called at the database is a process provided by and originating from the database itself, not caching intermediary 108 .
  • Databases typically provide various functionality for performance analysis, tuning, and debugging, etc.
  • Debugging facilities can provide information to database administrators (DBAs) and developers about how a query will be processed by the database. The facilities may analyze a query structure and specify which tables are accessed to process queries of that structure, how or in what order the tables are accessed, how the data from the tables are combined, and other types of information about how the database processes a query having the structure that was passed when calling the analysis facility.
  • an OracleTM database provides a debugging facility commonly referred to as “EXPLAIN PLAN.”
  • EXPLAIN PLAN a debugging facility commonly referred to as “EXPLAIN PLAN.”
  • the database will analyze how the database processes that particular query structure.
  • database 120 When database 120 receives the abstracted query skeleton 142 , it will execute the facility called by the intermediary when passing the skeleton. After analyzing skeleton 142 to determine how queries having the particular structure are processed, intermediary interface 112 accesses the results in order to determine the tables upon which queries of structure 142 are dependent. Different types of databases make these results available in different formats. For example, database 120 may create a table, file, or other data structure 150 with the results of its analysis and store it locally on disk 126 , for example. Interface 112 can access the results from disk to determine the dependencies for query structure 142 . An exemplary communication 144 from intermediary 112 to listener 128 instructing the listener to read results 150 from disk 126 is depicted in FIG. 3 .
  • listener 128 After reading the data from disk 126 , listener 128 provides the requested information to interface 112 as depicted by reply 145 .
  • a database may provide the data from an analysis by such a facility directly to the requesting application such as interface 112 .
  • a cache in accordance with one embodiment can call a native database analysis facility without having any predetermined knowledge of the query or the database protocols to be able to parse the query itself. This enables the cache to be implemented transparently to both requesting applications and databases. Importantly, the cache does not parse the query received from the requesting application. This enables the cache to interface with databases having different protocols, platforms, programming languages, and interfaces. Because the system calls a native facility at the database, it does not need to fully comprehend or be able to parse the queries it receives. The native database facility is relied upon for the required dependency analysis.
  • these native analysis facilities such as “EXPLAIN PLAN” are not intended or designed for use in caching operations as presently described. These facilities are typically provided for database administrators to manually issue queries to the database to analyze the performance of the database when executing a particular query. These tools are valuable to database administrators because they can design and restructure queries to maximize efficiency and performance by the database. By taking advantage of such facilities for caching query results, the complicated task of parsing queries is avoided while improving performance be reducing or eliminating parsing errors. Because of their intended application, these analysis facilities typically provide large amounts of information in addition to indicating the tables the database accesses in response to a particular query structure. In one embodiment, listener 128 filters the information received from the database in response to the query analysis to determine the tables accessed when executing the query.
  • intermediary 108 After receiving dependency information, intermediary 108 passes the actual query 140 to database 120 .
  • Database 120 executes the query and returns results 148 . If intermediary 108 determines that query 140 is a read query (as can be determined from the query structure analysis), a new entry is created in a dependency table listing skeleton 142 (if an entry does not already exist) and the dependencies determined by the database analysis facility.
  • Intermediary 108 also creates an entry in results table 204 for query 140 , specifying the query 140 , the results of the query provided by database 120 , and the time at which the results were obtained.
  • FIG. 3 conceptually depicts an update 143 issued from interface 112 to cache 110 specifying the data to be stored in the results and dependency tables. Processing of the query is complete when results 148 are provided to application 104 . It should be noted that the query and skeleton can be passed to the database in any order and the cache may determine the dependency information after receiving the actual query results.
  • intermediary 108 determines that query 140 is a write query, it updates or creates an entry in a modification table listing the tables effected by such a write query and the time at which the write query modified the tables. For example, if the write query modifies an employee table, and an entry already exists in modification table 208 for this table, the time at which that table is indicated to have last been modified is updated to reflect the new modification time. After updating or creating entries in the modification table, an indication is returned to application 104 that the query has been successfully processed.
  • an entry is included in dependency table 206 for write query structures and the tables modified by those write query structures.
  • a database analyzing a write query structure will provide information regarding the tables updated or modified by that query structure.
  • the dependency table can be accessed to determine if dependency information for that query's structure is already stored. If so, the actual query can be submitted to the database without passing the query structure to the database to determine the dependent tables.
  • the modification table can be directly updated.
  • the dependency table indicates whether a query is a write or read query and thus, whether the listed tables are modified by the query or whether the query is dependent upon those tables.
  • entries in table 204 affected by a write query are directly invalidated instead of updating times of last modification in table 208 that will be used later to determine if cached results are still valid.
  • each entry from table 204 can be read and the results of any queries that are dependent upon an updated table immediately invalidated.
  • the tables each query listed in the results table 204 is dependent upon is determined from dependency table 206 .
  • Intermediary 108 invalidates any results from the results table that depend upon an updated table. While such embodiments are possible, efficiency may decrease if numerous entries are listed in table 204 . By maintaining a list of the last update times for each table, better efficiency can be achieved by invalidating results only when a subsequent query corresponding to those results is received to avoid reading every entry from table 204 in response to any update to the database.
  • FIG. 4 is a flowchart of a method for processing the database queries and caching results thereof in accordance with one embodiment.
  • a caching system such as intermediary 108 executing at application server 102 , receives a query from an application at step 302 .
  • a results table is accessed at step 304 to determine whether an entry exists for the received query. If results are not being maintained for the received query, the query is abstracted at step 306 by removing any literal expressions or variable data.
  • a dependency table maintained by the caching system is accessed at step 308 to determine if an entry exists for the structure of the abstracted query. If an entry exists, the tables the query is dependent upon (read query) or the tables the query modifies (write query) are determined at step 310 . After determining the tables at step 310 , the unabstracted query is passed to the database at step 312 for processing. After processing the query, the database returns the results to the cache.
  • the abstracted query skeleton is passed to the database at step 314 by calling a native analysis facility provided by the database.
  • the query is passed onto the database and the results received at step 316 .
  • the results of the abstracted query analysis by the database are accessed at step 318 .
  • the cache determines whether the query was a write or read query at step 320 . If the query is a read query, an entry is created in the dependency table at step 322 setting forth the query structure and the table(s) the structure is dependent upon. If an entry already exists as determined at step 308 , step 322 is skipped.
  • results table 204 listing the actual query and the results received from the database upon passing the query at step 312 or 316 . These results are stored with an indication of the time they were received to facilitate subsequent data validity determinations. The results of the query are returned to the requesting application at step 326 .
  • step 320 if the received query is determined to be a write query, an entry is created in the dependency table at step 328 setting forth the query structure and the table(s) queries of that structure modify. Any entries in modification table 208 that correspond to tables affected by the received query are updated at step 330 to reflect the time of the latest update by the query. If no entry or entries exists in table 208 for the table(s) updated by the received query, new entries are created. After updating and/or creating the entries at step 330 , a response is returned to the requesting application at step 332 indicating that the query has been successfully processed.
  • table 206 is accessed at step 334 to determine what tables the query is dependent upon after abstracting the query.
  • modification table 208 is accessed at step 336 to determine the last time each dependent table was last updated. If any dependent table was updated after the time of retrieval for the query results as reflected in the time stamp at the results table, the results are determined to be invalid at step 338 .
  • the actual query is then passed to the database at step 340 and the results of the query received.
  • Results table 204 is updated at step 342 to reflect the new results for the query that were received from the database.
  • the cache also adjusts the time for the query in the results table to reflect the time the new results were retrieved.
  • the results of the query are returned to the requesting application at step 344 from the cache after determining that the query results are valid at step 336 . Otherwise, the results received at step 338 from the database are returned at step 344 .
  • FIG. 2 illustrates the detection of updates to a database directly by a caching intermediary in response to a received query and structural analysis provided by the database for the query. It is also possible for updates to a database to be made without a caching intermediary detecting them. For example, an application accessing the database from a location outside of application server 102 may send queries that do not pass through the caching intermediary. Other applications implemented on different application servers with their own communication links to database server 122 may send updates that do not pass through the intermediary. Database administrators or other users may directly modify the database through an administration interface provided by the database. Such updates may be referred to generally as backend updates.
  • FIG. 5 illustrates a backend update 166 to database 120 originating from an entity beyond application server 102 .
  • Update 166 is received directly at database server 120 and does not pass through the caching intermediary 108 at application server 102 .
  • a backend update is described for exemplary purposes, it is noted that updates that pass through the caching intermediary may also be detected through the hereinafter explained techniques, in addition to being directly detected by the intermediary.
  • databases typically maintain portions of user data in local memory for performance considerations.
  • Databases may aggregate updates to the database over a period of time and write them all to disk at once in the background when it has ample bandwidth and resources to do so.
  • Databases typically maintain a log or other identification reflecting all updates to the database in order to track the updates that have propagated to disk and those that are currently only maintained in local memory.
  • a query that updates one or more tables in database 120 can be processed, and the updated results maintained in a memory local to the database such as a software memory or a fast volatile memory such as RAM.
  • Subsequently received queries that reference this data before it is written to the database tables in non-volatile memory are processed using the updated data in local memory.
  • Database 120 may accumulate numerous updates to the database from various queries before writing updated data to the tables or other data structures stored on disk 126 or other non-volatile memory.
  • the log maintained by a database is continuously updated and written to a non-volatile memory such as disk 126 . If power loss occurs, causing data maintained in local memory at the database to be lost, the transaction log enables the database to “replay” any lost transactions to recover data not written to disk before the power loss.
  • the database can read the transaction log, compare it with the data stored on disk, and if any updates reflected in the log have not yet propagated to disk, update the appropriate tables on disk in accordance with the information in the transaction log.
  • a transaction log 152 is maintained by database 120 and stored on disk 126 .
  • Listener 128 can utilize this transaction log to detect all changes to database 120 regardless of origin.
  • database 120 receives a query, such as query 166 , specifying an update to one or more tables
  • the database calls the operating system to write information relating to the query to the transaction log 152 at disk 126 .
  • Database 120 causes the transaction log to be updated, in addition to making the changes specified by the query in local memory.
  • Listener 128 can access the updated transaction log 152 on disk 126 to determine if changes were made to database data.
  • listener 128 detects an update to the database, it notifies caching intermediary 108 that an update has been made as shown by communication 188 .
  • the intermediary can update a modification table to reflect the time at which the tables corresponding to any previously listed entries were updated, and to add new entries and modification times for any updated tables not already listed.
  • intermediary 108 can update a results table 204 by invalidating or deleting those entries dependent upon an updated table.
  • FIG. 6 is a flowchart depicting one embodiment for updating a cache based on detecting changes to data at the database.
  • a database server-side component monitors changes to a database transaction log to detect and report changes to database data to a caching intermediary remote from the database server.
  • a transaction log or other indication of transactional updates to the database is accessed at step 352 .
  • a server-side listener component 128 reads the transaction log and at step 354 compares the most recent data from the transaction log with data read from a previous version of the transaction log. If the listener detects changes to the transaction log, it makes a determination at step 356 that the database data has been modified. If no changes to the transaction log are detected, the listener determines that the database data has not been modified. In one embodiment, selected tables of the database are monitored while others are ignored. Listener 128 can be configured to determine that a change to monitored database data has occurred when a change to the transaction by reflecting an update to one of the monitored tables if detected. In one embodiment, listener 128 detects all changes to the log and database but only reports changes to specified tables.
  • the listener formulates an update to be sent to the caching intermediary at the application server.
  • An update is sent to the caching intermediary at the application server at step 358 .
  • the intermediary will update its local cache results and tables at step 360 to reflect the changes to the database. For example, an indication of the time a table was last modified as maintained in a modification table 208 can be updated to reflect the time of this latest update.
  • the caching intermediary can optionally send a reply at step 362 to the listener indicating that the necessary updates have been completed.
  • the listener After receiving the success response at step 362 or determining that no monitored tables have been updated at step 356 , the listener will read the transaction log again at step 352 to determine if more updates have been made. In one embodiment, a delay is implemented before accessing the transaction log again at step 352 . Additionally, the listener may not wait for a success response from the cache before accessing the transaction log again after sending an update at step 358 .
  • listener 128 is configured as a debugger for a native facility or process associated with database 120 .
  • listener 128 via an operating system 124 , can gain access to and control operations performed by database 120 .
  • Databases typically provide a facility or process that is responsible for writing data to transaction log 152 in accordance with updates to the database. This type of facility is commonly referred to as a log writer process for the database. By disguising itself as a debugger for a database's log writer process, listener 128 can be notified when transaction log 152 is updated, access the transaction log or information stored therein, and notify the cache of any relevant updates.
  • the exemplary embodiment presented therein includes a listener 128 configured as a debugger for a native log writer process 154 of database 120 .
  • Listener 128 attaches itself to the database through log writer 154 in such a manner to be notified of successful write operations to disk 126 that update or create transaction log 152 .
  • Database 120 receives query 166 , specifying an update to one or more tables of the database.
  • the database initially updates any data it is storing in local memory to reflect the changes made by query 166 .
  • Database 120 also updates any copy of transaction log 152 it is maintaining in local memory to reflect the updates.
  • Log writer process 154 is responsible for updating and writing transaction log 152 to disk 126 when updates to the database are made.
  • Database 120 via logwriter process 154 , sends a write command 182 to update the file for transaction log 152 stored on disk 126 in order to reflect the updates made by query 166 .
  • Write command 182 is received by operating system 124 , which forwards the write command 182 to disk 126 , typically via a disk driver (file system) for the disk.
  • disk 126 When disk 126 has successfully written the data for transaction log 152 , it sends a response 184 to operating system 124 indicating that the data was successfully written.
  • listener 128 instructs operating system 124 to notify it when updates are made to transaction log 152 by log writer process 154 .
  • listener 128 is configured to be notified when operating system 124 receives a write request for transaction log 152 from log writer process 154 .
  • When operating system 124 receives write request 182 it notifies listener 128 at 186 that a write request for the transaction log has been received.
  • Operating system 124 passes the new or updated data written to transaction log 152 in response to update 166 to listener 128 , as indicated at 186 . In another embodiment, the operating system passes the full transaction log to listener 128 .
  • Listener 128 parses the information received from operating system 124 to determine the nature of the database changes. If the listener determines that the updates made by query 166 effect one or more tables of database 120 that it is configured to monitor, a notification 188 is provided to caching intermediary 108 so that it can invalidate any query results that are dependent on the updated table(s). In one embodiment, the intermediary updates information maintained locally to indicate the time at which the tables were modified, by modifying or creating new entries in a modification table such as table 208 . In one embodiment, listener 128 is configured to be notified when a write operation for transaction log 152 has been successfully completed. When operating system 124 receives the success response from disk 126 , it can notify listener 128 at 186 that a successful write operation to the transaction log has been completed.
  • operating system 124 When operating system 124 receives success response 184 from disk 126 , it will also reply to database 120 with success response 190 informing it that the transaction log was successfully updated.
  • Log writer process 154 receives response 190 and can issue a response to the requesting application that its update was successfully processed.
  • databases will temporarily stop processing updates to database data while the transaction log is writing the log to disk.
  • Databases my further refrain from responding to read queries with updated data until that data has been successfully written to the log file maintained in non-volatile memory. This avoids data inconsistencies should the data in local memory be lost after it has been provided in response to a read request but before it is written to non-volatile memory.
  • Log writer process 154 can pause database 120 from further write and/or read query processing while it is writing the transaction log. When success response 190 is received, log writer process 154 knows the updated data for the database is now maintained in non-volatile memory. Accordingly, the log writer process will free the database 120 to continue processing queries.
  • log writer process 154 will process success response 190 and then release the database to use and respond with the newly updated data as well as process new queries.
  • intermediary 108 receives update 188 from listener 128 , it updates its cached data as required to invalidate any effected result entries in results table 204 . If the intermediary updates its records after database 120 is released to begin responding and using the new data from query 166 , intermediary 108 may return old data in response to a query.
  • a read query is received by intermediary 108 after database 120 is released to use and respond with the new data from query 166 , but before the intermediary updates its records to reflect that the relevant old entries are no longer valid.
  • the intermediary may return the cached results from its local memory to the requesting application since it is unaware of the changes made to the database by query 150 .
  • FIG. 7 is a flowchart of a method in accordance with one embodiment for detecting changes to a database using a listener configured as a debugger for a native database facility responsible for updating transactional information to document changes to the database.
  • a technique is implemented to ensure that a caching intermediary is updated in response to changes to the database before the database is released to begin using and responding to requests with the new data.
  • the listener presents itself as a debugger to the operating system at the database server.
  • debuggers can gain access and control over select portions of code, applications, or entire systems.
  • the listener By implementing the listener as a debugger for a portion of the database, the listener can take control of that portion to receive information regarding updates at the database from the database itself. Because the listener is disguised as a debugger, the operating system is instructed to notify the listener of select actions and allow the listener to take control of select actions to receive this updated information. The listener can thus take control of a portion of the database to ensure that the caching intermediary is updated before the database begins using updated data. While such an implementation is broadly and generally described as a debugger, it will be understood that the listener can gain access and control of portions of the database using other suitable techniques, such as through various instrumentations of the database source or object code.
  • the database receives an update to data stored in the database (e.g., write query) at step 370 .
  • the database updates its local memory at step 372 to reflect the changes made by the write query.
  • the database updates its transaction log in local memory at step 374 to reflect the updates made by the query.
  • the database sends a command to the operating system at step 376 to write the new information to the transaction log stored on a local non-volatile storage medium disk.
  • a log writer process is responsible for writing the transaction log to disk and issues a write command to the operating system at step 376 .
  • the operating system issues a write command to update the transaction log at the disk responsible for storing the transaction log.
  • the write command which includes the new information from the query, is received at the listener component at step 378 .
  • the listener component is configured as a debugger for the log writer process so that the operating system forwards the write request to it for processing.
  • the listener presents itself as a debugger in order to gain access and control of the log writer process to receive the transaction log updates.
  • the listener forwards the write request to the disk at step 382 and receives a response that the data was successfully written at step 380 .
  • the listener is further configured to pause the log writer process at step 834 when a success response is received from the disk indicating an update to the transaction log.
  • listener 128 pauses the log writer process by instructing the operating system not to return the success response to the database.
  • the listener temporarily pauses the log writer process to insure that the caching intermediary at the application server has updated its local cache results updated in accordance with the write or update query.
  • Database 120 will not use the new data provided by the query until it receives a notification that the transaction log has successfully been written to disk.
  • the listener parses the information received from the operating system at step 386 after the log writer process has been paused.
  • the listener determines the tables modified by the query. If tables the listener was configured to monitor were updated, an update is sent at step 388 to the caching intermediary at the application server.
  • the caching intermediary updates its locally stored information (e.g., modification table 208 ) to reflect the time at which the tables were modified by the query.
  • the caching intermediary After the caching intermediary successfully updates its data, it provides a success response to the listener at step 392 . Upon receipt of the response, the listener instructs the operating system at step 394 to release the log writer process. At step 396 , a success response indicating that the transaction log was successfully written is issued to the log writer process. The log writer process releases database 120 to use the new data from the query at step 398 . In this manner, the database will only use new data after that data has propagated to the caching intermediary. Thus, each cache can remain in a consistent and accurate data state with respect to the actual database.
  • the listener is configured to be notified of updates to the transaction log before they are written to disk.
  • the listener component can be notified of updates by the operating system when a write command is issued to the disk to update the transaction log. If updates are made to tables which the listener is monitoring, the listener begins updating the caches at the application level prior to the disk handling the write command. It is possible that the transaction log will not be successfully written to disk and thus, the database not updated with the new data.
  • the caching intermediary may invalidate cached results that are still valid as a result. While invalidations may occur more often than necessary in this scenario, no data consistency issues will exist. The intermediary will simply provide queries to the database for which it was maintaining valid results in its cache.
  • the listener is not limited to the particular structure of any disclosed arrangement and can be tailored to the requirements of individual implementations.
  • the listener is configured as a file system driver for the disk on which the database transaction log is to be stored.
  • the database After the database receives an update to the database data, it issues a command to the operating system to write the new information to the transaction log on disk.
  • the operating system issues this write command to an interface for the disk adapted to translate internal addresses used by the operating system to addresses understood by the disk.
  • the listener can disguise itself as the disk interface or driver for the disk storing the transaction log in order to intercept commands issued to the disk via the disk interface.
  • the listener will receive the command and forward it to the actual file system driver for the disk.
  • the file system will pass the command to the disk and receive a success response in return when the data is successfully written.
  • the listener can be configured to access the transaction log or the data passed in the write command to be written to the transaction log to defect updates to database data.
  • the listener accesses the data written to the transaction log when the write command is issued to the file system for the disk.
  • the listener accesses this information when a success response is received from the disk after the data has been written. In either case, the listener parses the information it receives and provides an update to the caching intermediary if necessary.
  • the listener can pass the success response received from the disk to the operating system immediately upon receipt.
  • the operating system will send a success response to the database, freeing the database to use the upload information. This scenario can lead to data inconsistencies between the cache and database as previously described.
  • the listener pauses the log writer process after receiving the success response from disk.
  • the listener will wait until it receives a success response from the caching intermediary before issuing the success response to the operating system.
  • the listener ensures data consistency as already described.
  • Stored procedures represent an increased level of complexity for caching systems associated with databases.
  • Stored procedures define a set of one or more operations and are stored at a database in a compiled format to be called by requesting applications to receive the results of the operations.
  • Stored procedures typically include a set of SQL statements.
  • Applications or developers wishing to access a stored procedure simply need to know the stored procedure's name, rather than schema, indexing, and column information required to develop a query.
  • stored procedures can include operational code.
  • Stored procedures can execute a set of code, call other databases to access or modify records, directly access other files, and/or access and transmit other information, such as by calling other applications.
  • Stored procedures are valuable, if not essential, components of many database installations.
  • Caching techniques that rely on parsing queries received from requesting applications are unable to handle stored procedures.
  • a stored procedure is only definable and understood by the database on which it is stored. For example, a typical stored procedure as seen by an application or application server will simply be a textual invocation of the procedure such as foo( ). Any application or caching system interfacing with the database does not know the internal operations defined by foo( ), and thus, can only see this textual call or issue similar calls to access the procedure. Parsing such a call to a stored procedure will not reveal anything about the individual queries the stored procedure references or the commands it executes at the database.
  • databases In order to run stored procedures, databases typically perform an analysis before run-time to assess how the stored procedure is processed. For example, the database may compile the stored procedure, examining the structure of the procedure, the individual queries the database tables accessed, in what manner and order the tables are accessed, as well as the various other operations that the database may perform as part of the stored procedure. The database may maintain this information or compiled process locally to increase performance when a request for this stored procedure is received. In this manner, the database does not have to determine this information each time the stored procedure is called.
  • the preparatory work by the database for a stored procedure amounts to compiling the stored procedure for run-time execution.
  • FIG. 8 depicts one embodiment for caching stored procedures.
  • Application 104 issues a request 402 for a stored procedure 403 maintained at database 120 .
  • Application 104 can issue a call 402 to a stored procedure 403 and pass one or more variable values.
  • Intermediary 108 can intercept the request as previously described for simple queries by wrapping itself around the native database driver 106 .
  • Intermediary 108 opens a trace session at the database when it determines the request is for a stored procedure.
  • trace sessions are typically used and designed for debugging.
  • a tracing process (e.g., 161 ) can collect various types of information associated with an application, system, or section of code during a period of time during which the trace is open.
  • a tracing facility provided by an application can allow a user of the application to observe files accessed, files modified, new files created, applications called, methods called, and various other types of operations associated with the application.
  • Various facilities provided by databases to track and document operations the database performs during a period of time may commonly be referred to as tracing facilities.
  • An OracleTM database application provides a facility called “trace.”
  • Other database vendors and types have similar but differently named facilities to perform these processes.
  • the intermediary After opening the trace session with database 120 , the intermediary issues the stored procedure call 402 to the database.
  • Database 120 receives call 402 and executes stored procedure 403 by performing the various functions and queries specified by the stored procedure.
  • Database 120 returns the results 406 of the stored procedure to intermediary 108 when it is complete.
  • the results 406 of stored procedure 403 are cached in a results table such as table 204 at the intermediary in the same manner query results are cached.
  • An identification of stored procedure 403 including the literal expressions passed with stored procedure call 402 , are maintained along with the results 406 received from the database 120 .
  • intermediary 108 When intermediary 108 receives the results, indicating that the stored procedure has been executed, it also closes the trace session with database 120 .
  • database 120 When the trace session is closed, database 120 generates a results file 409 , which in the embodiment of FIG. 8 is stored at local disk 206 in response to write command 408 .
  • the database may create and update the trace file while the trace session is opened in other embodiments. Different databases record the results of trace sessions in different ways. Databases may create a trace file containing information about the actions taken while the trace session was opened. Other databases may return information directly to the application opening the trace session.
  • the technology described herein is not limited to any particular type of database or native facility, and it is anticipated that the particular facility used may vary according to the requirements of a particular implementation.
  • Intermediary 108 accesses the trace information from file 409 to determine the queries executed at the database when performing stored procedure 403 .
  • intermediary 108 issues a request 410 to listener 128 to read trace file 409 from disk 126 .
  • Listener 128 responds by issuing a read request 412 to operating system 124 .
  • the request is forwarded to the disk which returns the file to the operating system as indicated at 414 .
  • the operating system forwards the file to listener 128 .
  • Listener 128 parses the information in the trace file to determine the individual queries that users executed to perform stored procedure 403 .
  • Listener 128 can select the queries executed in response to the stored procedure by identifying those queries from the trace file that include an identification associated with the caching intermediary.
  • Trace files may contain information identifying all operations, queries, etc. a database performs while a trace session is open, regardless of the originating application to which the database was responding. Databases typically store an identification of the application or process initiating each query in the trace file which the listener can use to select only those queries executed for procedure 403 .
  • a list 416 of queries executed in response to the stored procedure is sent from listener 128 to intermediary 108 after the trace file has been parsed. From this list, intermediary 108 determines every query executed at the database in response to stored procedure 403 . The intermediary determines each query executed by a stored procedure without parsing the stored procedure or the call issued by application 104 .
  • intermediary 108 determines which, if any, tables at the database were modified by the stored procedure. This determination is made as previously described for a standard query received at the cache.
  • Intermediary 108 abstracts each individual query and passes it to the database by calling a native database analysis facility to analyze how it processes a query of that structure. The abstracted query 418 is passed to database 120 which analyzes it and returns results 420 to interface 112 identifying any modified tables.
  • Intermediary 108 creates or modifies any entries in tables 206 and 208 associated with portions of the database affected by stored procedure 403 .
  • An entry is created (if not already existing) in table 206 for the structure of stored procedure 403 , along with the tables the stored procedure is dependent upon.
  • the intermediary can abstract a stored procedure in the same manner as a query by removing any literal expressions or variable data from the stored procedure call.
  • Interface 112 can list the abstracted stored procedure call in cache 110 with an indication of the tables the stored procedure is dependent on. The dependencies are determined from individual query abstraction analyzed by the database.
  • table 206 can further include an indication of the tables the stored procedure modifies.
  • Table 206 can include an indication for each listed table whether the procedure depends on that tables or modifies that table.
  • intermediary 108 lists any tables the stored procedure modifies with an indication of the last time that table was modified. For any pre-existing entries, the intermediary updates the indication of the last time of modification.
  • FIG. 9 is a flowchart depicting a method in accordance with one embodiment for caching database stored procedures.
  • a request or call for a stored procedure maintained at a database is received at step 702 .
  • a results table containing previously received results for various stored procedures and/or queries is accessed to determine whether an entry is present for the stored procedure referenced by the call. If an entry does not exist for the particular stored procedure, the stored procedure is abstracted at step 706 and a dependency table such as table 206 is accessed to determine if an entry is present for stored procedures having the structure of the received query at step 708 . If an entry for the query's structure is not present in the dependency table, a trace session is opened at the database at step 710 .
  • a request can be issued to the database to track the operations, transaction, queries, etc. processed while the trace session is open.
  • the stored procedure request is forwarded to the database at step 712 .
  • the database executes the stored procedure at step 714 by performing the actions specified in the stored procedure using the data passed with the request.
  • the database traces its actions performed while executing the stored procedure at step 716 and creates a file or other indication of the trace analysis.
  • the database returns the results at step 718 .
  • the caching intermediary can receive the results and store them in a results table at step 720 .
  • An indication of the stored procedure along with the results of its execution can be stored in a results table such as 204 .
  • the results are returned to the requesting application at step 722 .
  • the trace session at the database is closed at step 724 . In one embodiment, the trace session is closed when the results from the database are received.
  • the caching intermediary can issue a request to access the trace information at step 725 if it is not automatically returned as previously described.
  • a request can be issued to a listener installed at the database machine to read a file such as trace file 409 storing the trace data.
  • the listener can issue a read command and parse the information received from the requested trace file.
  • the listener can return all or a portion of this data to the caching system at step 726 .
  • the listener parses the data and returns a list of the queries executed by the database for the stored procedure.
  • the listener can pass the entire trace file to the intermediary which can perform the proper analysis to determine the queries.
  • the trace information is automatically returned to the requesting application such that steps 725 - 726 can be skipped.
  • the queries that are executed as part of the stored procedure are determined at step 727 .
  • Each query executed as part of the stored procedure is abstracted at step 728 by removing any literal expressions from the query.
  • Each abstracted query or skeleton is passed to the database at step 730 by calling a native facility of the database to analyze the structure of each query.
  • the results for each query skeleton are accessed at step 732 .
  • the intermediary creates an entry in a dependency table such as table 206 at step 734 .
  • Each entry will include a stored procedure skeleton and the tables it is dependent upon.
  • any tables modified by the stored procedure are also listed in the corresponding entry.
  • the table can include an indication of whether a listed table is a dependency of the query or a table modified by the query.
  • entries in a dependency modification table such as table 208 are created or updated for any tables modified by the stored procedure.
  • a dependency modification table such as table 208 are created or updated for any tables modified by the stored procedure.
  • an existing entry in the modification table can be updated with the time the stored procedure modified the corresponding database table if an entry for the table already exists. If an entry for the table does not already exist, a new entry is created by listing the table and time of modification.
  • the results table, dependency table, and modification table can be used for future stored procedure requests to determine whether results at the cache are validated and can be returned instead of retrieving them from the database itself.
  • step 708 If it is determined at step 708 that the structure of the stored procedure is already cached in a table such as 206 , for example, the dependencies of the stored procedure structure are determined at step 756 .
  • a call to the stored procedure is issued at step 758 and the results received.
  • the results are cached by the intermediary in the results table.
  • the results are returned to the requesting application at step 762 .
  • the modification table 208 is updated at step 764 if the stored procedure includes write queries.
  • the dependency table is accessed at step 736 to determine the tables the stored procedure is dependent upon.
  • the stored procedure can be abstracted to determine if an entry in the dependency table exists for queries of the received query's structure.
  • the time of last modification of each dependent table is determined at step 742 .
  • the cached results are not valid and are not returned to the requesting application.
  • a call to the stored procedure at the database is then issued at step 746 and the results received.
  • the results of the stored procedure are stored in the cache at step 748 with an indication of the time they were obtained.
  • the results are returned to the requesting application at step 750 .
  • the modification table is updated at step 752 to reflect the time of the latest updates if the stored procedure modifies any tables.
  • the results are returned to the requesting application at step 754 .
  • stored procedures can include write queries as well as read queries.
  • a call to a stored procedure is issued to the database even when the results of the procedure maintained by the cache are valid and can be returned to the requesting application.
  • the stored procedure is issued so that the updates to the database by the write portions of the procedure can be made.
  • the cached results can still be returned to increase performance in responding to applications.
  • the caching system can update the modification table to reflect the time of the new updates. Additionally, the results can be used to update the results table with new results for the stored procedure and the time these results were retrieved.
  • the results table and/or dependency table can include an indication for each stored procedure entry whether that stored procedure modifies any data at the database.
  • An embodiment that specifies whether each table in the dependency table is updated by the corresponding stored procedure or whether the stored procedure modifies the listed table has already been described.
  • the intermediary determines that a requested procedure contains a valid entry in the results table and the procedure does not modify data at the database, the cached results are returned and the stored procedure is not passed to the database. If the entry indicates that the stored procedure does modify data, it can be passed to the database to modify database data after returning the cached results to the requesting application.
  • a caching system is implemented to only cache stored procedure results and other information for procedures that do not modify data at the database.
  • the embodiments described thus far have described table based caching systems that invalidate entries when a dependent table of a query is modified.
  • the disclosed techniques are extendable to other levels of invalidation based on more refined analysis of modified data.
  • the disclosed technology can be used to invalidate cached query results when a row the query is dependent upon is modified.
  • results can be invalidated only when an actual entry in the database the query is dependent upon is modified.
  • FIG. 10 is a flowchart depicting a row-based caching and invalidation technique in accordance with one embodiment.
  • the employee record with the salary column updated to a value above $100,000 should now be included in the query results. However, the update does not affect any rows that were returned in response to the original query. If invalidation is based only on changes to those records or rows included in the original results, row-based caching in this example would fail to properly invalidate the cached results and invalid results returned for a subsequent received version of this query.
  • a query is received from a requesting application at step 802 and at 804 , it is determined whether an entry corresponding to the received query exists in a results table. If there is no corresponding entry in the results table, the query is abstracted at step 806 and a determination made at step 808 as to whether an entry for the abstracted query skeleton exists in a dependency table.
  • the resulting skeleton is passed to the database at step 810 by calling a native analysis facility of the database to assess how the query structure is handled.
  • the results of the analysis are accessed at step 812 .
  • an entry is created in the dependency table for the query skeleton.
  • Dependency tables in the row-based technique depicted in FIG. 10 are implemented as previously described with respect to table-based caching. The entry lists the abstracted query skeleton and any tables queries having that structure are dependent upon.
  • step 816 it is determined whether the query requests records based solely on a unique identifier for individual records of the corresponding table. If the query depends solely on a unique identifier for a row of the relevant table, the process continues at step 818 where it is determined if the query is a write or read query. If the query is a read query, the query is modified at step 820 to include a request for the row ID number of the record requested by the query. Each record in a table includes an internal identifier used by the database to uniquely identify every record. This identifier or row ID number is different than the unique user data identifier referred to previously.
  • the modified query is passed to the database at step 822 .
  • the results of the query are received from the database at step 824 .
  • the query results are used to create an entry in results table 204 at step 826 .
  • the entry created in table 204 will not only include the query, the results, and the time the results were obtained, but also the row ID number associated with that query that was retrieved via the modified query.
  • the row ID number is used to determine whether cached query results are valid when subsequent requests including the cached query are received.
  • the query results are returned to the requesting application at step 828 . If the cached system determines at step 818 that the query is a write query, a modification table is updated at step 830 to indicate the modifications to the tables effected by the write query.
  • the modification table stores an indication of the times rows within a table were last updated.
  • the modification table is updated to include the table dependencies determined at step 812 .
  • the modification will specify the row_id for the specific record(s) modified by the query as well as the table that was modified and the time of modification. If it is determined at step 816 that the query does not requests records based solely on a unique identifier for individual records of the corresponding table, the method continues at step 832 where table based caching is instituted according to steps 320 - 332 of FIG. 4 . Steps 322 and 328 are skipped if the query's structure is already cached.
  • the dependencies for the query are determined at step 834 .
  • the tables the query is dependent upon are determined from dependency table 206 .
  • the row_id number of the query is determined from results table 204 at step 836 .
  • Modification table 208 is then searched at step 838 for an entry matching the dependent table of the query and the row_id number of the query. If an entry is found and the time of last modification to the specified row was before the results stored in table 204 were obtained, the cached results are determined to be valid at step 840 .
  • the cached results are returned to the requesting application at step 842 .
  • the cached results are valid and they are returned at step 842 . If an entry is found and it indicates an update to the row after the results were obtained, the query is passed to the database at step 844 and the results received. The results are provided to the requesting application at step 846 .
  • table 208 may only list table identifications for certain entries along with the time the table was modified when the entry is for a query that is dependent on something other than a unique record identifier.
  • Table 208 may also include entries including row ID numbers and table IDs for other entries.
  • entries in table 204 for the query results may list the row_id numbers for queries meeting the unique row identifier dependency limitation. For more complicated queries with additional dependencies, only the results and time will be maintained. In this manner, when a query is received that has an entry in table 204 , an intermediary can determine the row ID dependency from table 206 in order to compare that dependency with the time of last update from table 208 to determine whether the results in table 204 are valid.
  • a caching system can be distributed across one or more servers or other systems at various levels to provide further performance and availability.
  • FIG. 11 depicts an exemplary embodiment including caching intermediaries 108 distributed at application servers 102 as well as a central server 902 .
  • Central server 902 is implemented between application servers 102 and database server 122 to provide an additional level of caching.
  • Each application server includes a caching intermediary 108 as previously described.
  • Central server 902 also includes a caching intermediary 108 , providing a centralized cache for results and invalidation information that can be used by the individual intermediaries at each application server.
  • the caching intermediary 108 at the central server includes similar cache 110 and interface 112 components as the local caching intermediaries. These components may include additional operations and perform slightly different operations in such a multi-level environment. Again, different implementations of intermediary 108 can be made in accordance with embodiments.
  • the listener component 128 interfaces with the caching intermediary 108 at the central server 902 to provide information regarding updates to the database. The intermediary at the central server can maintain this information for invalidating cache entries.
  • the central server intermediary can pass this information to the local intermediaries at the application servers so it can be used there for invalidations.
  • the listener component 128 can interface directly with each caching intermediary 108 at the application server level and central server level.
  • an application 104 at any of the application servers can issue a query or stored procedure call which is intercepted at the local caching intermediary 108 associated with that application.
  • the caching intermediary can determine if it is storing dependency information for the structure of the received query. If the structure is stored locally, the local intermediary can determine if it is storing valid results for the received query as previously described. If the local intermediary is storing valid results, it can further access the central server's intermediary 108 to assess the validity of the results.
  • An application at one of the other application servers in communication with the central server may update database 120 in a transaction not seen at the local intermediary processing the current request.
  • a query received from any of the local application servers will pass through central server 902 .
  • the local intermediary can access the central server to determine the last time any table, row, etc. upon which the received query is dependent was last modified by any of the applications at any of the application servers. If the local intermediary determines that its local results are valid, those results can be returned to the requesting application. If the local results are not valid, the local intermediary passes the query to the caching intermediary at the central server 902 . The caching intermediary at central server 902 will return its locally cached results if they are valid.
  • the intermediary at the central server will forward the query to the database and receive results.
  • the intermediary at the central server will update its cache with the new results, time of retrieval, and/or any portions of the database modified by the query if necessary.
  • the results will be returned to the local intermediary which will also update its cache in accordance with the new results, time, etc.
  • the central server's caching intermediary can also send the results and any update information to the local intermediaries at the application servers in response to updates to the database from any of the application servers and/or in response to a direct update detected by listener component 128 .
  • the local intermediaries need only check their local caches to determine if their cached results are still valid.
  • the local intermediary receiving the query initially determines that it is not storing dependency information for the structure of the received query, it can abstract the query and pass it to the intermediary at the central server to determine if the intermediary at the central server is maintaining the dependency information. For example, dependency analysis may have already been performed by the database for the received structure in response to a query from another application server. If the intermediary at the central server is maintaining the information, it can pass it to the local intermediary which can cache the information for later use. Upon receiving the dependency information in one embodiment, the local intermediary determines that it is not storing valid results for the query and forwards the query to the central server's intermediary. In other embodiments, the local intermediary can pass the query to the central server's intermediary as soon as it determines that it is not storing the dependency information, rather than wait to receive this information.
  • the database If the database is not storing the dependency information for a query of this structure, it will send a response to the local intermediary informing it that the query structure has not yet been analyzed or that queries of that structure are not cacheable.
  • the central server intermediary stores information to indicate query structures that were previously determined to not be cacheable to avoid the performance of dependency analysis more than once for the same structure. Additionally, the local intermediaries can maintain information about query structures that were previously determined to not be cacheable so that a request to the central server can be avoided when it is known that queries of the received structure are not cacheable.
  • the local intermediary After receiving a notification from the central server intermediary that the dependency information is not being stored or that queries of the received query's structure are not cacheable, the local intermediary sends the actual query to the intermediary at the central server.
  • the local intermediary also sends the actual query to the intermediary after receiving dependency information and determining that it is not maintaining valid results for the actual query as mentioned above.
  • the central server intermediary can again check whether it is storing dependency information for the received query. In other embodiments, the central server intermediary only performs this check once.
  • the central server intermediary will pass the abstracted query to the database by calling a facility such as “EXPLAIN PLAN” as previously described.
  • the intermediary at the central server will also pass the actual query to the database.
  • the intermediary at the central server can cache the results and forward them to the local caching intermediary which will also cache the results.
  • the central server intermediary will cache the dependency information, etc. and forward the results to the local intermediary which will cache them as well.
  • the central server intermediary and local intermediaries wait to receive the dependency analysis information before caching query results or dependency information.
  • a dual-level caching system is provided with caches at the application server level and another server level implemented between the application servers and database server.
  • additional levels of caching can be used.
  • application server caching systems may interface with a regional server running a caching system in accordance with an embodiment.
  • Multiple regional servers may interface with a central server running a caching system that interfaces with the database system.
  • Other variations with additional levels of caching or further distribution of components across these servers can be implemented in accordance with various embodiments.
  • any type of processing or computing device may be used, including personal computers, minicomputers, mainframes, handheld computing devices, mobile computing devices, and so forth.
  • these computing devices will include one or more processors in communication with one or more processor readable storage devices, communication interfaces, peripheral devices, and so forth.
  • Examples of storage devices include RAM, ROM, hard disk drives, floppy disk drives, CD ROMS, DVDs, flash memory, and so forth.
  • Examples of peripherals include printers, monitors, keyboards, pointing devices, and so forth.
  • Examples of communication interfaces include network cards, modems, wireless transmitters/receivers, and so forth.
  • all or part of the functionality is implemented in software, including firmware and/or micro code, that is stored on one or more processor readable storage devices and is used to program one or more processors to achieve the functionality described herein.

Abstract

Database data is maintained reliably and invalidated based on actual changes to data in the database. Updates or changes to data are detected without parsing queries submitted to the database. The dependencies of a query can be determined by submitting a version of the received query to the database through a native facility provided by the database to analyze how query structures are processed. The caching system can access the results of the facility to determine the tables, rows, or other partitions of data a received query is dependent upon or modifies. An abstracted form of the query can be cached with an indication of the tables, rows, etc. that queries of that structure access or modify. The tables a write or update query modifies can be cached with a time of last modification. When a query is received for which the results are cached, the system can readily determine dependency information for the query, the last time the dependencies were modified, and compare this time with the time indicated for when the cached results were retrieved. By passing versions of write queries to the database, updates to the database can be detected.

Description

    PRIORITY CLAIM
  • This application claims the benefit of U.S. Provisional Patent Application No. 60/684,610, filed May 25, 2005, entitled “Terracotta Virtualization Server”, and incorporated by reference herein in its entirety.
  • CROSS-REFERENCE TO RELATED APPLICATIONS
  • The following applications are cross-referenced and incorporated by reference herein in their entirety:
  • U.S. patent application Ser. No. ______, filed concurrently, entitled “Database Caching and Invalidation Based on Detected Database Updates,” by Harward et al., filed concurrently (Attorney Docket No. TERA-01008US0); and
  • U.S. patent application Ser. No. ______, filed concurrently, entitled “Database Caching and Invalidation for Stored Procedures,” by Harward et al., filed concurrently (Attorney Docket No. TERA-01009US0).
  • BACKGROUND OF THE INVENTION
  • 1. Field of the Invention
  • The present invention relates generally to databases and caching systems for databases.
  • 2. Description of the Related Art
  • Databases are an integral part of many operations, businesses and organizations where access to structured data is needed. Databases offer manageability for the vast amounts of data that many of today's large scale enterprises rely upon in day to day operations. Through the use of database storage, seemingly incomprehensible amounts of data can be maintained in a structured environment so that requesting users can easily locate and retrieve needed information. Many of today's large-scale applications such as e-commerce, banking, etc. are able to present end-users with seemingly instant access to personalized information by using databases. Without database storage in many of these environments, the task of methodically sorting through the amount of information necessary to access that which is needed would likely frustrate the ultimate purpose of the application to the point of ending many operations.
  • Databases can be implemented in many languages and may support many protocols such as Structured Query Language (SQL) which provides users and applications the ability to interface with the database through SQL statements to select, insert, update, and delete information in the database. Of course, the complexity of operations performed by and submitted to databases continues to expand. SQL statements can be combined to provide a high level of logic and interaction with data in a database.
  • As the amount of data maintained by databases continues to expand, the efficiency and performance of database access and response becomes ever more crucial. For instance, a database maintaining banking records for users across the country or world must be able to efficiently respond to requests from numerous users accessing the database at the same time from various remote geographic locations.
  • Database caching techniques have been developed to decrease the amount of aggregate traffic transmitted between the database and requesting client devices. By caching database information in smaller faster memories, performance can be increased. Certain access requests will be satisfied from local cached versions of the database. This will not only increase the performance as seen by requesting applications or entities, but also decrease the amount of load placed on the database.
  • An inherent difficulty with database caching is the structured nature of both the data storage and retrieval. In traditional data caching scenarios, such as caching recently accessed data from a large memory volume that is indexed according to a physical or logical address, discrete data segments can be cached in a smaller memory and referenced according to their location on the large memory volume. The cache simply looks for an update to the location on the memory volume corresponding to the cached data and when the data at that location changes, the cache can simply invalidate or discard its cached results. In databases, however, data is retrieved by passing queries such as SQL statements. These statements can access, combine, and manipulate data from different locations to satisfy the query request.
  • Because of the structured nature of databases, database caches relying on these traditional caching techniques are required to store a subset of an entire database's data structures. Data is cached based on memory locations and entries invalidated based on updates to those memory locations. These systems do not cache results based on an actual query. Because queries may combine or access data from various locations in the database, and request data based on logic that is dependent upon the data stored therein, it is difficult to accurately determine when the previously retrieved results for a query are no longer valid because of changes to data in the database. Complex analysis to parse a received query is thus required to determine what the query does at the database. While in theory such a technique is useful, in practice it presents obstacles. Databases are typically written in a proprietary format and the underlying source code is not made available to those wishing to implement a caching system. Because an intimate knowledge of the database's internal operations and code can not be had, parsing the queries is in many instances deficient or even wrong. Moreover, individual database providers frequently alter their databases, requiring these parsing techniques to continually be updated as the database is updated.
  • In other implementations, schedule or time-based caching has been used for databases to overcome the difficulty with parsing queries. Entries in a cache are made for particular queries and the results of those queries. However, the entries are automatically invalidated after a specified amount of time without any regard to actual changes at the database. If changes to the database are made between invalidation periods and a request is received, the cache may return invalid results. Additionally, this technique can degrade performance and efficiency by needlessly invalidating accurate query results.
  • Accordingly, an improved system and technique for database caching is needed to provide efficient, reliable, and accurate results.
  • SUMMARY OF THE INVENTION
  • A database caching system and related techniques are provided that can reliably maintain and invalidate database data based on actual changes to data in the database. Updates or changes to data at the database are detected without parsing queries submitted to the database. The dependencies of a received query can be determined by submitting a version of the received query to the database through a native facility provided by the database itself to analyze how query structures are processed at the database. The caching system can access the results of the facility to determine the tables or rows (or other data partition) a received query is dependent upon or modifies. In addition to the results of a query that can be cached with an indication of the query itself, an abstracted form of the query can be cached with an indication of the tables, rows, etc. that queries of that structure access or modify. The tables a write or update query modifies can be cached with a time of their last modification. When a query is received for which the results are cached, the system can readily determine dependency information for the query, the last time the dependencies were modified, and compare this time with the time indicated for when the cached results were retrieved. By passing versions of write queries to the database, updates to the database can be detected. In one embodiment, a component is implemented at or on the system of the database to directly detect changes to the database data. This component can monitor transactional information maintained by the database itself to determine when changes to the database occur. This component can communicate with the cache to provide notification of changes to the database.
  • A method of caching database query results is provided in one embodiment that includes receiving a request for information from a database and determining if previously received results for the request are maintained locally. If previously received results are not maintained locally for the request, the method can include passing a form of the request to the database by calling a native analysis facility at the database to assess how the database processes requests of the form, accessing results of the assessment by the native analysis facility, determining from the results one or more dependencies of the database for requests of the form, maintaining data indicating that requests of the form for the database include the one or more dependencies, passing the request to the database and receiving results, and maintaining information including the request and the results of the request.
  • In one embodiment, a database caching system is provided that includes a database including a native analysis facility to analyze query structures and a caching intermediary in communication with the database and an application accessing the database. The caching intermediary maintains one or more queries and results received from the database in response to the one or more queries. The caching intermediary receives a first query from the application and determines if the first query and previously received results for the first query are maintained by the caching intermediary. The caching intermediary passes a form of the first query to the native analysis facility at the database if the caching intermediary is not maintaining results for the first query and accesses results of the analysis facility to determine one or more tables of the database upon which queries of the form depend. The caching intermediary further maintains the form of the first query and an indication of the one of more tables of the database upon which queries of the form depend.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 is a block diagram of a database caching system in accordance with one embodiment.
  • FIG. 2 depicts a database cache in accordance with one embodiment.
  • FIG. 3 is a block diagram of a database caching system in accordance with one embodiment, wherein processing and caching database queries is depicted.
  • FIG. 4 is a flowchart for processing and caching database queries in accordance with one embodiment.
  • FIG. 5 is a block diagram of a database caching system in accordance with one embodiment, wherein the detection of a backend update to the database, and subsequent update to the cache is depicted.
  • FIG. 6 is a flowchart for detecting updates to a database and updating a database cache according to the update in accordance with one embodiment.
  • FIG. 7 is a flowchart for monitoring updates to a database using a listener component implemented as a debugger for at least a portion of the database.
  • FIG. 8 is a block diagram of a database caching system in accordance with one embodiment, wherein processing and caching of database stored procedures is depicted.
  • FIG. 9 is a flowchart for processing and caching database stored procedures in accordance with one embodiment.
  • FIG. 10 is a flowchart for caching database queries and invalidating the results of the database queries based on row level updates to the database.
  • FIG. 11 is a block diagram of a multi-level database caching system in accordance with one embodiment.
  • DETAILED DESCRIPTION
  • Database Caching Intermediary
  • FIG. 1 is a block diagram depicting one embodiment of the technology described herein executing in an application server—database server environment. FIG. 1 depicts an application server 102 and database server 122. A variety of applications 104 can be hosted and executed upon application server 102. Applications 104 can be implemented in any suitable language, including but not limited to the Java™ programming language, C++, etc. The application servers on which applications 104 are executed will vary by embodiment, but can support such platforms as the Java™ 2 Platform, Enterprise Edition (J2EE) Platform.
  • In one embodiment, servers, processing systems, and other processor based devices as described can include, by way of non-limiting example, one or more processors capable of executing instructions provided on processor-readable media to perform the methods and tasks described herein. The processing system may include a volatile memory, a mass storage device or other non-volatile memory, a portable storage device, one or more communications or network interfaces and various I/O devices. A processing system hardware architecture as described is just one suitable example of a processing system suitable for implementing the present technology. While embodiments are presented with respect to exemplary server-based implementations, variations for stand-alone, client, and other suitable processing environments can be made without departing from the scope of the present disclosure.
  • The database server 122 hosts a database application 120. Database server 122 includes an operating system 124 and a non-volatile storage device 126 (such as a disk drive or RAID array). Numerous types of databases 120 can be used in accordance with embodiments of the disclosed technology. For example, database 120 can include a database provided by Oracle™ Corporation of Sunnyvale, Calif., a database provided by Sybase™ Corporation of Dublin, Calif., or a database provided by Microsoft™ Corporation of Redmond, Wash. The technology described herein is not limited to any particular type of database application. References to particular types and brands of databases and the particular functions of a type of database are presented for exemplary purposes and are not intended to limit the scope of the present disclosure or claimed subject matter. The extension of an embodied concept from an exemplary described database to a different type of database will be readily apparent to those of ordinary skill in the art. It is further noted that the disclosed server based implementations are exemplary and other implementations can be made on client devices hosting the database and/or caching system, for example. Moreover, multiple levels of caching in accordance with embodiments can be provided at one or more servers in addition to those indicated in FIG. 1. For example, a caching system implemented at a central server could interface between the components of database server 122 and those of multiple application servers. Cached results can be maintained and retrieved from the central server in addition to or in place of maintaining and receiving them at an intermediary cache at the application server level.
  • Interface 106 is provided at application server 102 to enable applications 104 access to database 120. Interface 106 will vary by implementation according to the type of programming platform and/or database provided. Interface 106 is provided in accordance with an Application Programming Interface (API) that provides connectivity between the programming language(s) and platforms associated with applications 104 and database 120. In many modern database implementations, interface 106 is implemented in accordance with the Java™ Database Connectivity (JDBC) API, an industry standard interface that provides database independent connectivity between the Java™ programming language and a wide range of databases. Interface 106 is a JDBC driver in one embodiment, implementing the JDBC API to provide a call level API for SQL-based database access. The JDBC driver can provide transparent access for applications 104 to database 120.
  • A database caching intermediary 108 is provided at application server 102 to increase the performance, reliability and availability of the information maintained by database 120 for requesting applications 104. Cache 108 can provide previously received results for queries or other requests/calls submitted to database 120 that are maintained locally at application server 102 to increase the performance and availability of database 120 while decreasing the response time for requests. Applications 104 request data from database 120 by submitting queries or other calls. For example, applications can submit commands formatted in accordance with the specifications of interface 106 (e.g., as JDBC commands) to provide SQL commands to database 120. Intermediary 108 can more quickly provide the results of a query if valid results are currently stored in the cache. Moreover, intermediary 108 can increase database availability by providing cached results when database 120 is inaccessible.
  • The structure of caching intermediary 108 may vary by implementation according to the requirements of a particular application. In the embodiment depicted in FIG. 1, caching intermediary 108 includes an intermediary interface or driver 112 and a cache 110. Interface 112 can provide and execute many of the disclosed operations while cache 110 maintains portions of the data from database 120 and internal data used by the caching intermediary 108 that can maintain portions of database 120 in local memory. Interface 112 conceptually wraps itself around native interface 106 to provide transparent intermediation between applications 104 and database 120. Applications 104 can communicate with interface 112 in the same manner they would with the native database interface. To requesting applications 104, interface 112 will appear the same as the native interface 106. By wrapping around the native interface, the intermediary interface forces applications 104 to communicate with the intermediary, instead of directly accessing interface 106.
  • In one embodiment, interface 112 is a HA-JDBC High Availability Java™ Database Connectivity (HA-JDBC) driver. Interface 112 will appear as a standard JDBC driver and thus provide a transparent solution to applications 104 for caching query results. Intermediary 108 can be installed and integrated into an existing system without modifying any application source or object code and without modifying any database source or object code. Applications 104 continue to access database 120 in the typical manner, appearing to interface directly with the native database driver 106, while in fact, interfacing with the intermediary driver 112 provided in accordance with one embodiment.
  • Caching intermediary 108 provides cached results that are maintained current and invalidated where appropriate based on updates to database 120 or events processed by database 120. Changed data within the database is the impetus for determining that cached database results are no longer valid. This contrasts with traditional database caches that operate as scheduled or time-based caches. For example, traditional schedule-based caches invalidate cached results based on a set schedule or time interval. Entries stored in the cache expire or are invalidated periodically based solely on an elapsed period of time. Invalidations occur in response to the mere passage of time without regard to any actual changes at the database. By using such a technique, these systems stand not only to return invalid data to requesting applications, but also to needlessly invalidate valid cached data and decrease performance.
  • Depending Analysis Using Native Database Facilities
  • Intermediary 108 can detect actual changes to database 120 and invalidate and/or update entries in cache 110 based on these updates rather than an elapsed period of time according to a predetermined schedule. In one embodiment, changes to database 120 are detected through queries submitted by applications 104 and received at the caching intermediary. In one embodiment, caching intermediary 108 is able to detect changes to database 120 made in response to queries without parsing the submitted queries. In one embodiment, the caching intermediary 108 calls a native analysis facility provided by and inherent to the database to analyze queries received from requesting applications. The analysis facility provides information regarding how a query submitted for analysis is processed by the database. Caching intermediary 108 can determine details of how the database processes the query, including the tables or other data partitions the database accesses to fulfill the requests.
  • It is important to note that the analysis facility called by caching intermediary 108 is a native facility or process provided by the database. This enables the intermediary to determine which tables of a database are accessed in responding to a query. Importantly, the intermediary is able to determine this information without parsing the actual query. Databases typically provide debugging and performance analysis facilities as native database procedures available to end-users. These facilities are traditionally used by database administrators to debug queries or to increase the performance associated with a particular query. An administrator may view how a query is processed and modify the query structure based on this review to maximize performance. Caching intermediary 108 can exploit one or more of these native facilities to determine the dependencies of queries it receives.
  • The use of native database facilities to determine this information is a strong departure from traditional caching techniques that rely on parsing queries. For example, intermediary 108 may call an “EXPLAIN PLAN” facility to determine the dependencies of a query submitted to an Oracle™ database. An abstracted or skeleton version of the query can be issued in a call to this facility to determine how such a query is processed and this, the tables accessed. Numerous types of native database facilities may be used in various embodiments depending on the type of database platform, programming language, or server platform.
  • The use of native database facilities to determine dependency and other information for a query is a significant and strong departure from traditional caching techniques that rely on query parsing, for example. To provide cached results based on changes to data in a database, previous techniques have relied on parsing the actual query received from an application to determine query dependencies, etc. These systems include an inherent limitation that it is difficult if not impossible to precisely parse a query without knowledge of the relevant database source code. Any cache provided by an entity without intimate knowledge of the database code will not be able to fully understand and parse queries designed for that database. The technology described herein avoids these inherent limitations by relying on the database itself to assess and provide the necessary information for caching to the intermediary.
  • FIG. 2 depicts an exemplary implementation of intermediary cache 110 in accordance with one embodiment. In FIG. 2, cache 110 includes three individual tables to facilitate caching and cache invalidation. A results table 204 maintains a list 210 of queries and the results 212 of those queries as retrieved from the database. Table 204 further includes an indication 214 of the time at which the query was processed and the results obtained from the database. In one embodiment, the results are time-stamped and the third column is not used.
  • Dependency table 206 maintains a list of query structures, also referred to as skeletons or footprints, along with a list of the tables from database 120 upon which queries of that structure are dependent. A query skeleton is a form of an actual query without any variable data or literal expressions. Literal expressions refer to the individual variables within a query for which input data is passed to the database to retrieve unique records. For example, a simple query (shown as entry 216 in table 204) that selects a record from an employee table where the user_id column is 12 will have a skeleton as shown by entry 222 in table 206. The skeleton shown is a form of the original query with the user_id literal expression “12” replaced with “:v.” All queries having the same skeleton will be processed in a similar manner and retrieve results from the same tables in the database. Any query having the structure of entry 222 is dependent upon the employee table. Replacing the literal expressions with “:v” is but one example of abstracting a query. Any suitable place holder can be used and in one embodiment, the literal sections are simply “marked off” using some external method (e.g., recording the indices of the start and end characters of each literal section). Modification table 208 tracks modifications or updates to the tables in database 120. Table 208 lists table from database 102 and the time at which the table was last updated. Using the tables of cache 110, the caching intermediary can determine if valid results are cached for a particular query. If results are listed in table 204 for a received query, table 206 is accessed to determine what tables the query is dependent upon. Table 208 is then accessed to determine when those tables were last modified. If the time of the last modification is before the time the results were obtained (table 204), the results are determined to be valid.
  • A listener component 128 is also provided to detect changes to data maintained by database 120. This component provides the additional benefit of being able to detect so-called backend updates to database 120 that do not pass through intermediary 108. For example, database 120 can be modified by a database administrator or other entity not in communication with intermediary 108. Listener component 128 can interface directly with the database at the database server to detect any backdoor updates that originate from beyond the reach or control of the caching intermediary.
  • In accordance with one embodiment, invalidations of cached database results are based on actual changes to database data. Updates to the database trigger the invalidation of cache entries within a caching intermediary. A more efficient cache is provided by avoiding unnecessary invalidations of cached results, as inherent in time-based caches. Furthermore, invalidations based on changed data as determined from the database provides consistency between data in the cache and data in the cache and database. Moreover, the reliance on the database to analyze queries and determine dependency information avoids the limitations associated with parsing queries submitted to a database for which the underlying code and operation is not well understood.
  • FIG. 3 is a simplified block diagram depicting the communication flow of a database caching system in accordance with one embodiment. Application 104 (e.g., Application A) at application server 102 communicates with caching intermediary 108 to access database 120, implemented at database server 122. Application 104 issues query 140 for execution by database 120. Query 140 is received at caching intermediary 108. When query 140 is received at the intermediary, the interface 112 accesses intermediary cache 110 to determine if the intermediary is maintaining valid results for query 140, retrieved from the database in response to a previous request including query 140.
  • Interface 112 accesses cache 110 as indicated at 141 and determines whether results for query 140 are currently maintained locally at the cache. If the results are currently stored—in results table 204 for example—the intermediary accesses a dependency table 206 at cache 110 to determine which tables at the database queries of the received query's structure are dependent upon. Table 208 is then accessed to determine the last time each table query 140 is dependent upon was last updated. The time the results stored in results table 204 were obtained is compared with the last time each dependent table was updated to determine whether the cached results were retrieved from the database after the last update to any dependent table of the query. If the results were retrieved after the last update the cached results are returned as indicated at 138.
  • If the results were retrieved before the last update or if no results are maintained, the database is accessed to process query 140. Interface 112 abstracts the query by removing the literal expressions from the query string to create a query skeleton 142 having the structure of query 140. After abstracting the query, intermediary interface 112 passes the skeleton 142 to the native database interface which forwards it to database 120. In one embodiment, interface 112 checks cache 110 first to determine if the dependency analysis information for the abstracted query is already stored. If so, the abstracted query is not passed.
  • If the query structure and dependencies of query 140 are not already stored, interface 112 passes query structure 142 by calling a native analysis or tuning facility 162 provided by database 120. The term native indicates that the facility or process called at the database is a process provided by and originating from the database itself, not caching intermediary 108. Databases typically provide various functionality for performance analysis, tuning, and debugging, etc. Debugging facilities can provide information to database administrators (DBAs) and developers about how a query will be processed by the database. The facilities may analyze a query structure and specify which tables are accessed to process queries of that structure, how or in what order the tables are accessed, how the data from the tables are combined, and other types of information about how the database processes a query having the structure that was passed when calling the analysis facility. These facilities provide information to DBAs, etc. so that queries can be restructured or modified to optimize processing at the database. In one embodiment for example, an Oracle™ database provides a debugging facility commonly referred to as “EXPLAIN PLAN.” In response to a call to the “EXPLAIN PLAN” facility passing a selected query structure for analysis, the database will analyze how the database processes that particular query structure.
  • When database 120 receives the abstracted query skeleton 142, it will execute the facility called by the intermediary when passing the skeleton. After analyzing skeleton 142 to determine how queries having the particular structure are processed, intermediary interface 112 accesses the results in order to determine the tables upon which queries of structure 142 are dependent. Different types of databases make these results available in different formats. For example, database 120 may create a table, file, or other data structure 150 with the results of its analysis and store it locally on disk 126, for example. Interface 112 can access the results from disk to determine the dependencies for query structure 142. An exemplary communication 144 from intermediary 112 to listener 128 instructing the listener to read results 150 from disk 126 is depicted in FIG. 3. After reading the data from disk 126, listener 128 provides the requested information to interface 112 as depicted by reply 145. In other embodiments, a database may provide the data from an analysis by such a facility directly to the requesting application such as interface 112.
  • Numerous types of analysis facilities are provided by databases that can be accessed in accordance with embodiments to determine query structures' dependency information. Embodiments of the technology described herein are not limited to any particular analysis facility provided by any particular database. It is important to note that a cache in accordance with one embodiment can call a native database analysis facility without having any predetermined knowledge of the query or the database protocols to be able to parse the query itself. This enables the cache to be implemented transparently to both requesting applications and databases. Importantly, the cache does not parse the query received from the requesting application. This enables the cache to interface with databases having different protocols, platforms, programming languages, and interfaces. Because the system calls a native facility at the database, it does not need to fully comprehend or be able to parse the queries it receives. The native database facility is relied upon for the required dependency analysis.
  • It is also important to note that these native analysis facilities such as “EXPLAIN PLAN” are not intended or designed for use in caching operations as presently described. These facilities are typically provided for database administrators to manually issue queries to the database to analyze the performance of the database when executing a particular query. These tools are valuable to database administrators because they can design and restructure queries to maximize efficiency and performance by the database. By taking advantage of such facilities for caching query results, the complicated task of parsing queries is avoided while improving performance be reducing or eliminating parsing errors. Because of their intended application, these analysis facilities typically provide large amounts of information in addition to indicating the tables the database accesses in response to a particular query structure. In one embodiment, listener 128 filters the information received from the database in response to the query analysis to determine the tables accessed when executing the query.
  • After receiving dependency information, intermediary 108 passes the actual query 140 to database 120. Database 120 executes the query and returns results 148. If intermediary 108 determines that query 140 is a read query (as can be determined from the query structure analysis), a new entry is created in a dependency table listing skeleton 142 (if an entry does not already exist) and the dependencies determined by the database analysis facility. Intermediary 108 also creates an entry in results table 204 for query 140, specifying the query 140, the results of the query provided by database 120, and the time at which the results were obtained. FIG. 3 conceptually depicts an update 143 issued from interface 112 to cache 110 specifying the data to be stored in the results and dependency tables. Processing of the query is complete when results 148 are provided to application 104. It should be noted that the query and skeleton can be passed to the database in any order and the cache may determine the dependency information after receiving the actual query results.
  • If intermediary 108 determines that query 140 is a write query, it updates or creates an entry in a modification table listing the tables effected by such a write query and the time at which the write query modified the tables. For example, if the write query modifies an employee table, and an entry already exists in modification table 208 for this table, the time at which that table is indicated to have last been modified is updated to reflect the new modification time. After updating or creating entries in the modification table, an indication is returned to application 104 that the query has been successfully processed.
  • In one embodiment, an entry is included in dependency table 206 for write query structures and the tables modified by those write query structures. A database analyzing a write query structure will provide information regarding the tables updated or modified by that query structure. When a query is subsequently received, the dependency table can be accessed to determine if dependency information for that query's structure is already stored. If so, the actual query can be submitted to the database without passing the query structure to the database to determine the dependent tables. When the results are received, the modification table can be directly updated. In one embodiment, the dependency table indicates whether a query is a write or read query and thus, whether the listed tables are modified by the query or whether the query is dependent upon those tables.
  • In an alternate embodiment, entries in table 204 affected by a write query are directly invalidated instead of updating times of last modification in table 208 that will be used later to determine if cached results are still valid. For example, each entry from table 204 can be read and the results of any queries that are dependent upon an updated table immediately invalidated. In one embodiment, the tables each query listed in the results table 204 is dependent upon is determined from dependency table 206. Intermediary 108 invalidates any results from the results table that depend upon an updated table. While such embodiments are possible, efficiency may decrease if numerous entries are listed in table 204. By maintaining a list of the last update times for each table, better efficiency can be achieved by invalidating results only when a subsequent query corresponding to those results is received to avoid reading every entry from table 204 in response to any update to the database.
  • FIG. 4 is a flowchart of a method for processing the database queries and caching results thereof in accordance with one embodiment. A caching system, such as intermediary 108 executing at application server 102, receives a query from an application at step 302. A results table is accessed at step 304 to determine whether an entry exists for the received query. If results are not being maintained for the received query, the query is abstracted at step 306 by removing any literal expressions or variable data.
  • After abstracting the query, a dependency table maintained by the caching system is accessed at step 308 to determine if an entry exists for the structure of the abstracted query. If an entry exists, the tables the query is dependent upon (read query) or the tables the query modifies (write query) are determined at step 310. After determining the tables at step 310, the unabstracted query is passed to the database at step 312 for processing. After processing the query, the database returns the results to the cache.
  • If the abstracted query structure is not stored in the dependency table, the abstracted query skeleton is passed to the database at step 314 by calling a native analysis facility provided by the database. The query is passed onto the database and the results received at step 316. The results of the abstracted query analysis by the database are accessed at step 318. From the results accessed at step 318 or step 310, the cache determines whether the query was a write or read query at step 320. If the query is a read query, an entry is created in the dependency table at step 322 setting forth the query structure and the table(s) the structure is dependent upon. If an entry already exists as determined at step 308, step 322 is skipped. An entry is created in results table 204 at step 324 listing the actual query and the results received from the database upon passing the query at step 312 or 316. These results are stored with an indication of the time they were received to facilitate subsequent data validity determinations. The results of the query are returned to the requesting application at step 326.
  • Returning to step 320, if the received query is determined to be a write query, an entry is created in the dependency table at step 328 setting forth the query structure and the table(s) queries of that structure modify. Any entries in modification table 208 that correspond to tables affected by the received query are updated at step 330 to reflect the time of the latest update by the query. If no entry or entries exists in table 208 for the table(s) updated by the received query, new entries are created. After updating and/or creating the entries at step 330, a response is returned to the requesting application at step 332 indicating that the query has been successfully processed.
  • If it is determined at step 304 that an entry in results table 204 for the received query already exists, table 206 is accessed at step 334 to determine what tables the query is dependent upon after abstracting the query. After determining the dependent tables, modification table 208 is accessed at step 336 to determine the last time each dependent table was last updated. If any dependent table was updated after the time of retrieval for the query results as reflected in the time stamp at the results table, the results are determined to be invalid at step 338. The actual query is then passed to the database at step 340 and the results of the query received. Results table 204 is updated at step 342 to reflect the new results for the query that were received from the database. The cache also adjusts the time for the query in the results table to reflect the time the new results were retrieved.
  • The results of the query are returned to the requesting application at step 344 from the cache after determining that the query results are valid at step 336. Otherwise, the results received at step 338 from the database are returned at step 344.
  • Database Listener
  • FIG. 2 illustrates the detection of updates to a database directly by a caching intermediary in response to a received query and structural analysis provided by the database for the query. It is also possible for updates to a database to be made without a caching intermediary detecting them. For example, an application accessing the database from a location outside of application server 102 may send queries that do not pass through the caching intermediary. Other applications implemented on different application servers with their own communication links to database server 122 may send updates that do not pass through the intermediary. Database administrators or other users may directly modify the database through an administration interface provided by the database. Such updates may be referred to generally as backend updates.
  • FIG. 5 illustrates a backend update 166 to database 120 originating from an entity beyond application server 102. Update 166 is received directly at database server 120 and does not pass through the caching intermediary 108 at application server 102. Although a backend update is described for exemplary purposes, it is noted that updates that pass through the caching intermediary may also be detected through the hereinafter explained techniques, in addition to being directly detected by the intermediary.
  • As understood by those of ordinary skill in the art, databases typically maintain portions of user data in local memory for performance considerations. Databases may aggregate updates to the database over a period of time and write them all to disk at once in the background when it has ample bandwidth and resources to do so. Databases typically maintain a log or other identification reflecting all updates to the database in order to track the updates that have propagated to disk and those that are currently only maintained in local memory. A query that updates one or more tables in database 120 can be processed, and the updated results maintained in a memory local to the database such as a software memory or a fast volatile memory such as RAM. Subsequently received queries that reference this data before it is written to the database tables in non-volatile memory are processed using the updated data in local memory. Database 120 may accumulate numerous updates to the database from various queries before writing updated data to the tables or other data structures stored on disk 126 or other non-volatile memory.
  • The log maintained by a database, often referred to as a transaction log, is continuously updated and written to a non-volatile memory such as disk 126. If power loss occurs, causing data maintained in local memory at the database to be lost, the transaction log enables the database to “replay” any lost transactions to recover data not written to disk before the power loss. Upon reboot, the database can read the transaction log, compare it with the data stored on disk, and if any updates reflected in the log have not yet propagated to disk, update the appropriate tables on disk in accordance with the information in the transaction log.
  • In FIG. 5, a transaction log 152 is maintained by database 120 and stored on disk 126. Listener 128 can utilize this transaction log to detect all changes to database 120 regardless of origin. When database 120 receives a query, such as query 166, specifying an update to one or more tables, the database calls the operating system to write information relating to the query to the transaction log 152 at disk 126. Database 120 causes the transaction log to be updated, in addition to making the changes specified by the query in local memory. Listener 128 can access the updated transaction log 152 on disk 126 to determine if changes were made to database data. When listener 128 detects an update to the database, it notifies caching intermediary 108 that an update has been made as shown by communication 188. The intermediary can update a modification table to reflect the time at which the tables corresponding to any previously listed entries were updated, and to add new entries and modification times for any updated tables not already listed. In one embodiment where cached results are invalidated immediately upon detecting an update and a table such as table 208 is not used, intermediary 108 can update a results table 204 by invalidating or deleting those entries dependent upon an updated table.
  • FIG. 6 is a flowchart depicting one embodiment for updating a cache based on detecting changes to data at the database. In FIG. 6, a database server-side component monitors changes to a database transaction log to detect and report changes to database data to a caching intermediary remote from the database server.
  • A transaction log or other indication of transactional updates to the database is accessed at step 352. A server-side listener component 128 reads the transaction log and at step 354 compares the most recent data from the transaction log with data read from a previous version of the transaction log. If the listener detects changes to the transaction log, it makes a determination at step 356 that the database data has been modified. If no changes to the transaction log are detected, the listener determines that the database data has not been modified. In one embodiment, selected tables of the database are monitored while others are ignored. Listener 128 can be configured to determine that a change to monitored database data has occurred when a change to the transaction by reflecting an update to one of the monitored tables if detected. In one embodiment, listener 128 detects all changes to the log and database but only reports changes to specified tables.
  • When an update to database data, or an update to selectively monitored data is detected, the listener formulates an update to be sent to the caching intermediary at the application server. An update is sent to the caching intermediary at the application server at step 358. The intermediary will update its local cache results and tables at step 360 to reflect the changes to the database. For example, an indication of the time a table was last modified as maintained in a modification table 208 can be updated to reflect the time of this latest update. After the local cache is updated, the caching intermediary can optionally send a reply at step 362 to the listener indicating that the necessary updates have been completed. After receiving the success response at step 362 or determining that no monitored tables have been updated at step 356, the listener will read the transaction log again at step 352 to determine if more updates have been made. In one embodiment, a delay is implemented before accessing the transaction log again at step 352. Additionally, the listener may not wait for a success response from the cache before accessing the transaction log again after sending an update at step 358.
  • In one exemplary embodiment, listener 128 is configured as a debugger for a native facility or process associated with database 120. As a debugger for a process executed by the database, listener 128, via an operating system 124, can gain access to and control operations performed by database 120.
  • Databases typically provide a facility or process that is responsible for writing data to transaction log 152 in accordance with updates to the database. This type of facility is commonly referred to as a log writer process for the database. By disguising itself as a debugger for a database's log writer process, listener 128 can be notified when transaction log 152 is updated, access the transaction log or information stored therein, and notify the cache of any relevant updates.
  • Referring again to FIG. 5, the exemplary embodiment presented therein includes a listener 128 configured as a debugger for a native log writer process 154 of database 120. Listener 128 attaches itself to the database through log writer 154 in such a manner to be notified of successful write operations to disk 126 that update or create transaction log 152.
  • Database 120 receives query 166, specifying an update to one or more tables of the database. The database initially updates any data it is storing in local memory to reflect the changes made by query 166. Database 120 also updates any copy of transaction log 152 it is maintaining in local memory to reflect the updates.
  • Log writer process 154 is responsible for updating and writing transaction log 152 to disk 126 when updates to the database are made. Database 120, via logwriter process 154, sends a write command 182 to update the file for transaction log 152 stored on disk 126 in order to reflect the updates made by query 166. Write command 182 is received by operating system 124, which forwards the write command 182 to disk 126, typically via a disk driver (file system) for the disk. When disk 126 has successfully written the data for transaction log 152, it sends a response 184 to operating system 124 indicating that the data was successfully written.
  • As a debugger for log writer process 154, listener 128 instructs operating system 124 to notify it when updates are made to transaction log 152 by log writer process 154. In FIG. 5, listener 128 is configured to be notified when operating system 124 receives a write request for transaction log 152 from log writer process 154. When operating system 124 receives write request 182, it notifies listener 128 at 186 that a write request for the transaction log has been received. Operating system 124 passes the new or updated data written to transaction log 152 in response to update 166 to listener 128, as indicated at 186. In another embodiment, the operating system passes the full transaction log to listener 128. Listener 128 parses the information received from operating system 124 to determine the nature of the database changes. If the listener determines that the updates made by query 166 effect one or more tables of database 120 that it is configured to monitor, a notification 188 is provided to caching intermediary 108 so that it can invalidate any query results that are dependent on the updated table(s). In one embodiment, the intermediary updates information maintained locally to indicate the time at which the tables were modified, by modifying or creating new entries in a modification table such as table 208. In one embodiment, listener 128 is configured to be notified when a write operation for transaction log 152 has been successfully completed. When operating system 124 receives the success response from disk 126, it can notify listener 128 at 186 that a successful write operation to the transaction log has been completed.
  • When operating system 124 receives success response 184 from disk 126, it will also reply to database 120 with success response 190 informing it that the transaction log was successfully updated. Log writer process 154 receives response 190 and can issue a response to the requesting application that its update was successfully processed.
  • It is possible in a configuration like that of FIG. 5 that an update from listener 128 to intermediary 108 may not be processed in sufficient time to avoid returning old or no longer valid data to requesting applications. Typically, databases will temporarily stop processing updates to database data while the transaction log is writing the log to disk. Databases my further refrain from responding to read queries with updated data until that data has been successfully written to the log file maintained in non-volatile memory. This avoids data inconsistencies should the data in local memory be lost after it has been provided in response to a read request but before it is written to non-volatile memory. Log writer process 154 can pause database 120 from further write and/or read query processing while it is writing the transaction log. When success response 190 is received, log writer process 154 knows the updated data for the database is now maintained in non-volatile memory. Accordingly, the log writer process will free the database 120 to continue processing queries.
  • Consider a situation where listener 128 and database 120 receive responses 186 and 190, respectively, at the same time. Log writer process 154 will process success response 190 and then release the database to use and respond with the newly updated data as well as process new queries. When intermediary 108 receives update 188 from listener 128, it updates its cached data as required to invalidate any effected result entries in results table 204. If the intermediary updates its records after database 120 is released to begin responding and using the new data from query 166, intermediary 108 may return old data in response to a query. Imagine that a read query is received by intermediary 108 after database 120 is released to use and respond with the new data from query 166, but before the intermediary updates its records to reflect that the relevant old entries are no longer valid. The intermediary may return the cached results from its local memory to the requesting application since it is unaware of the changes made to the database by query 150.
  • FIG. 7 is a flowchart of a method in accordance with one embodiment for detecting changes to a database using a listener configured as a debugger for a native database facility responsible for updating transactional information to document changes to the database. In the embodiment of FIG. 7, a technique is implemented to ensure that a caching intermediary is updated in response to changes to the database before the database is released to begin using and responding to requests with the new data. The listener presents itself as a debugger to the operating system at the database server. As understood by those of ordinary skill, debuggers can gain access and control over select portions of code, applications, or entire systems. By implementing the listener as a debugger for a portion of the database, the listener can take control of that portion to receive information regarding updates at the database from the database itself. Because the listener is disguised as a debugger, the operating system is instructed to notify the listener of select actions and allow the listener to take control of select actions to receive this updated information. The listener can thus take control of a portion of the database to ensure that the caching intermediary is updated before the database begins using updated data. While such an implementation is broadly and generally described as a debugger, it will be understood that the listener can gain access and control of portions of the database using other suitable techniques, such as through various instrumentations of the database source or object code.
  • The database receives an update to data stored in the database (e.g., write query) at step 370. The database updates its local memory at step 372 to reflect the changes made by the write query. The database updates its transaction log in local memory at step 374 to reflect the updates made by the query. The database sends a command to the operating system at step 376 to write the new information to the transaction log stored on a local non-volatile storage medium disk. In one embodiment, a log writer process is responsible for writing the transaction log to disk and issues a write command to the operating system at step 376.
  • At step 378, the operating system issues a write command to update the transaction log at the disk responsible for storing the transaction log. The write command, which includes the new information from the query, is received at the listener component at step 378. The listener component is configured as a debugger for the log writer process so that the operating system forwards the write request to it for processing. The listener presents itself as a debugger in order to gain access and control of the log writer process to receive the transaction log updates. The listener forwards the write request to the disk at step 382 and receives a response that the data was successfully written at step 380.
  • The listener is further configured to pause the log writer process at step 834 when a success response is received from the disk indicating an update to the transaction log. In one embodiment, listener 128 pauses the log writer process by instructing the operating system not to return the success response to the database. The listener temporarily pauses the log writer process to insure that the caching intermediary at the application server has updated its local cache results updated in accordance with the write or update query. Database 120 will not use the new data provided by the query until it receives a notification that the transaction log has successfully been written to disk.
  • The listener parses the information received from the operating system at step 386 after the log writer process has been paused. The listener determines the tables modified by the query. If tables the listener was configured to monitor were updated, an update is sent at step 388 to the caching intermediary at the application server. At step 390, the caching intermediary updates its locally stored information (e.g., modification table 208) to reflect the time at which the tables were modified by the query.
  • After the caching intermediary successfully updates its data, it provides a success response to the listener at step 392. Upon receipt of the response, the listener instructs the operating system at step 394 to release the log writer process. At step 396, a success response indicating that the transaction log was successfully written is issued to the log writer process. The log writer process releases database 120 to use the new data from the query at step 398. In this manner, the database will only use new data after that data has propagated to the caching intermediary. Thus, each cache can remain in a consistent and accurate data state with respect to the actual database.
  • In one embodiment, the listener is configured to be notified of updates to the transaction log before they are written to disk. For example, the listener component can be notified of updates by the operating system when a write command is issued to the disk to update the transaction log. If updates are made to tables which the listener is monitoring, the listener begins updating the caches at the application level prior to the disk handling the write command. It is possible that the transaction log will not be successfully written to disk and thus, the database not updated with the new data. The caching intermediary may invalidate cached results that are still valid as a result. While invalidations may occur more often than necessary in this scenario, no data consistency issues will exist. The intermediary will simply provide queries to the database for which it was maintaining valid results in its cache.
  • The listener is not limited to the particular structure of any disclosed arrangement and can be tailored to the requirements of individual implementations. In one embodiment, the listener is configured as a file system driver for the disk on which the database transaction log is to be stored. After the database receives an update to the database data, it issues a command to the operating system to write the new information to the transaction log on disk. The operating system issues this write command to an interface for the disk adapted to translate internal addresses used by the operating system to addresses understood by the disk. The listener can disguise itself as the disk interface or driver for the disk storing the transaction log in order to intercept commands issued to the disk via the disk interface.
  • The listener will receive the command and forward it to the actual file system driver for the disk. The file system will pass the command to the disk and receive a success response in return when the data is successfully written. The listener can be configured to access the transaction log or the data passed in the write command to be written to the transaction log to defect updates to database data. In one embodiment, the listener accesses the data written to the transaction log when the write command is issued to the file system for the disk. In another embodiment, the listener accesses this information when a success response is received from the disk after the data has been written. In either case, the listener parses the information it receives and provides an update to the caching intermediary if necessary.
  • Similarly to the debugger configuration, the listener can pass the success response received from the disk to the operating system immediately upon receipt. The operating system will send a success response to the database, freeing the database to use the upload information. This scenario can lead to data inconsistencies between the cache and database as previously described.
  • In another embodiment, the listener pauses the log writer process after receiving the success response from disk. The listener will wait until it receives a success response from the caching intermediary before issuing the success response to the operating system. By pausing the log writer process until the cache is updated, the listener ensures data consistency as already described.
  • Caching Stored Procedures and Invalidating Results
  • Stored procedures represent an increased level of complexity for caching systems associated with databases. Stored procedures define a set of one or more operations and are stored at a database in a compiled format to be called by requesting applications to receive the results of the operations. Stored procedures typically include a set of SQL statements. Applications or developers wishing to access a stored procedure simply need to know the stored procedure's name, rather than schema, indexing, and column information required to develop a query. In addition to SQL statements, stored procedures can include operational code. Stored procedures can execute a set of code, call other databases to access or modify records, directly access other files, and/or access and transmit other information, such as by calling other applications. Stored procedures are valuable, if not essential, components of many database installations. They provide centralized query management for institutions, grouping operations and call commands for increased security and to avoid errors, etc. when writing individual queries and application code. Stored procedures improve database performance by reducing the total traffic between applications and the database. An application can call a stored procedure once to execute numerous queries and receive a single set of results, rather than issue each individual query and receive a result for each issued query. The pre-compiled nature of stored procedures provides significant improvements in performance when compared to traditional query statements. Stored procedures are compiled just once by the database which reuses the compiled process whenever the procedure is called. Queries on the other hand, are compiled each time the query is executed.
  • Caching techniques that rely on parsing queries received from requesting applications are unable to handle stored procedures. A stored procedure is only definable and understood by the database on which it is stored. For example, a typical stored procedure as seen by an application or application server will simply be a textual invocation of the procedure such as foo( ). Any application or caching system interfacing with the database does not know the internal operations defined by foo( ), and thus, can only see this textual call or issue similar calls to access the procedure. Parsing such a call to a stored procedure will not reveal anything about the individual queries the stored procedure references or the commands it executes at the database.
  • In order to run stored procedures, databases typically perform an analysis before run-time to assess how the stored procedure is processed. For example, the database may compile the stored procedure, examining the structure of the procedure, the individual queries the database tables accessed, in what manner and order the tables are accessed, as well as the various other operations that the database may perform as part of the stored procedure. The database may maintain this information or compiled process locally to increase performance when a request for this stored procedure is received. In this manner, the database does not have to determine this information each time the stored procedure is called. Conceptually, the preparatory work by the database for a stored procedure amounts to compiling the stored procedure for run-time execution.
  • In accordance with one embodiment of the technology described herein, stored procedures are successfully cached and the results invalidated based on changed data in the database. FIG. 8 depicts one embodiment for caching stored procedures. Application 104 issues a request 402 for a stored procedure 403 maintained at database 120.
  • Application 104 (e.g., Application A) can issue a call 402 to a stored procedure 403 and pass one or more variable values. Intermediary 108 can intercept the request as previously described for simple queries by wrapping itself around the native database driver 106. Intermediary 108 opens a trace session at the database when it determines the request is for a stored procedure. As understood by those of ordinary skill in the art, trace sessions are typically used and designed for debugging. A tracing process (e.g., 161) can collect various types of information associated with an application, system, or section of code during a period of time during which the trace is open. For example, a tracing facility provided by an application can allow a user of the application to observe files accessed, files modified, new files created, applications called, methods called, and various other types of operations associated with the application. Various facilities provided by databases to track and document operations the database performs during a period of time may commonly be referred to as tracing facilities. An Oracle™ database application provides a facility called “trace.” Other database vendors and types have similar but differently named facilities to perform these processes.
  • After opening the trace session with database 120, the intermediary issues the stored procedure call 402 to the database. Database 120 receives call 402 and executes stored procedure 403 by performing the various functions and queries specified by the stored procedure. Database 120 returns the results 406 of the stored procedure to intermediary 108 when it is complete. The results 406 of stored procedure 403 are cached in a results table such as table 204 at the intermediary in the same manner query results are cached. An identification of stored procedure 403, including the literal expressions passed with stored procedure call 402, are maintained along with the results 406 received from the database 120.
  • When intermediary 108 receives the results, indicating that the stored procedure has been executed, it also closes the trace session with database 120. When the trace session is closed, database 120 generates a results file 409, which in the embodiment of FIG. 8 is stored at local disk 206 in response to write command 408. The database may create and update the trace file while the trace session is opened in other embodiments. Different databases record the results of trace sessions in different ways. Databases may create a trace file containing information about the actions taken while the trace session was opened. Other databases may return information directly to the application opening the trace session. The technology described herein is not limited to any particular type of database or native facility, and it is anticipated that the particular facility used may vary according to the requirements of a particular implementation.
  • Intermediary 108 accesses the trace information from file 409 to determine the queries executed at the database when performing stored procedure 403. In the embodiment of FIG. 8, intermediary 108 issues a request 410 to listener 128 to read trace file 409 from disk 126. Listener 128 responds by issuing a read request 412 to operating system 124. The request is forwarded to the disk which returns the file to the operating system as indicated at 414. The operating system forwards the file to listener 128. Listener 128 parses the information in the trace file to determine the individual queries that users executed to perform stored procedure 403. Listener 128 can select the queries executed in response to the stored procedure by identifying those queries from the trace file that include an identification associated with the caching intermediary. Trace files may contain information identifying all operations, queries, etc. a database performs while a trace session is open, regardless of the originating application to which the database was responding. Databases typically store an identification of the application or process initiating each query in the trace file which the listener can use to select only those queries executed for procedure 403.
  • A list 416 of queries executed in response to the stored procedure is sent from listener 128 to intermediary 108 after the trace file has been parsed. From this list, intermediary 108 determines every query executed at the database in response to stored procedure 403. The intermediary determines each query executed by a stored procedure without parsing the stored procedure or the call issued by application 104.
  • Having determined the queries executed in response to stored procedure 403, intermediary 108 determines which, if any, tables at the database were modified by the stored procedure. This determination is made as previously described for a standard query received at the cache. Intermediary 108 abstracts each individual query and passes it to the database by calling a native database analysis facility to analyze how it processes a query of that structure. The abstracted query 418 is passed to database 120 which analyzes it and returns results 420 to interface 112 identifying any modified tables.
  • Intermediary 108 creates or modifies any entries in tables 206 and 208 associated with portions of the database affected by stored procedure 403. An entry is created (if not already existing) in table 206 for the structure of stored procedure 403, along with the tables the stored procedure is dependent upon. The intermediary can abstract a stored procedure in the same manner as a query by removing any literal expressions or variable data from the stored procedure call. Interface 112 can list the abstracted stored procedure call in cache 110 with an indication of the tables the stored procedure is dependent on. The dependencies are determined from individual query abstraction analyzed by the database. For stored procedures, table 206 can further include an indication of the tables the stored procedure modifies. Table 206 can include an indication for each listed table whether the procedure depends on that tables or modifies that table. In table 208, intermediary 108 lists any tables the stored procedure modifies with an indication of the last time that table was modified. For any pre-existing entries, the intermediary updates the indication of the last time of modification.
  • FIG. 9 is a flowchart depicting a method in accordance with one embodiment for caching database stored procedures. A request or call for a stored procedure maintained at a database is received at step 702. At step 704, a results table containing previously received results for various stored procedures and/or queries is accessed to determine whether an entry is present for the stored procedure referenced by the call. If an entry does not exist for the particular stored procedure, the stored procedure is abstracted at step 706 and a dependency table such as table 206 is accessed to determine if an entry is present for stored procedures having the structure of the received query at step 708. If an entry for the query's structure is not present in the dependency table, a trace session is opened at the database at step 710. A request can be issued to the database to track the operations, transaction, queries, etc. processed while the trace session is open. After opening the trace session, the stored procedure request is forwarded to the database at step 712. The database executes the stored procedure at step 714 by performing the actions specified in the stored procedure using the data passed with the request. The database traces its actions performed while executing the stored procedure at step 716 and creates a file or other indication of the trace analysis. After executing the stored procedure, the database returns the results at step 718. The caching intermediary can receive the results and store them in a results table at step 720. An indication of the stored procedure along with the results of its execution can be stored in a results table such as 204. The results are returned to the requesting application at step 722. After caching the results of the stored procedure, the trace session at the database is closed at step 724. In one embodiment, the trace session is closed when the results from the database are received.
  • The caching intermediary can issue a request to access the trace information at step 725 if it is not automatically returned as previously described. For example, a request can be issued to a listener installed at the database machine to read a file such as trace file 409 storing the trace data. The listener can issue a read command and parse the information received from the requested trace file. The listener can return all or a portion of this data to the caching system at step 726. In one embodiment, the listener parses the data and returns a list of the queries executed by the database for the stored procedure. In other embodiments, the listener can pass the entire trace file to the intermediary which can perform the proper analysis to determine the queries. IN one embodiment, the trace information is automatically returned to the requesting application such that steps 725-726 can be skipped. In any event, the queries that are executed as part of the stored procedure are determined at step 727.
  • Each query executed as part of the stored procedure is abstracted at step 728 by removing any literal expressions from the query. Each abstracted query or skeleton is passed to the database at step 730 by calling a native facility of the database to analyze the structure of each query. The results for each query skeleton are accessed at step 732. The intermediary creates an entry in a dependency table such as table 206 at step 734. Each entry will include a stored procedure skeleton and the tables it is dependent upon. In one embodiment, any tables modified by the stored procedure are also listed in the corresponding entry. The table can include an indication of whether a listed table is a dependency of the query or a table modified by the query. At step 736, entries in a dependency modification table such as table 208 are created or updated for any tables modified by the stored procedure. For each table that was updated in response to the stored procedure command, an existing entry in the modification table can be updated with the time the stored procedure modified the corresponding database table if an entry for the table already exists. If an entry for the table does not already exist, a new entry is created by listing the table and time of modification. The results table, dependency table, and modification table can be used for future stored procedure requests to determine whether results at the cache are validated and can be returned instead of retrieving them from the database itself.
  • If it is determined at step 708 that the structure of the stored procedure is already cached in a table such as 206, for example, the dependencies of the stored procedure structure are determined at step 756. A call to the stored procedure is issued at step 758 and the results received. At step 760, the results are cached by the intermediary in the results table. The results are returned to the requesting application at step 762. The modification table 208 is updated at step 764 if the stored procedure includes write queries.
  • If it is determined at step 704 that an entry in the results table already exists for the stored procedure, the dependency table is accessed at step 736 to determine the tables the stored procedure is dependent upon. The stored procedure can be abstracted to determine if an entry in the dependency table exists for queries of the received query's structure. The time of last modification of each dependent table is determined at step 742. At step 744, it is determined whether the cached results are still valid. In one embodiment, a time stamp for the results determined from the results table is compared with the times listed in the modification table for each table the stored procedure is dependent upon. If the results in the results table were retrieved before an update to one or more of the tables modified by the stored procedure as indicated in the modification table, the cached results are not valid and are not returned to the requesting application. A call to the stored procedure at the database is then issued at step 746 and the results received. The results of the stored procedure are stored in the cache at step 748 with an indication of the time they were obtained. The results are returned to the requesting application at step 750. The modification table is updated at step 752 to reflect the time of the latest updates if the stored procedure modifies any tables.
  • If the cached results are determined at step 744 to be valid, the results are returned to the requesting application at step 754. As mentioned, stored procedures can include write queries as well as read queries. In one embodiment, a call to a stored procedure is issued to the database even when the results of the procedure maintained by the cache are valid and can be returned to the requesting application. The stored procedure is issued so that the updates to the database by the write portions of the procedure can be made. The cached results can still be returned to increase performance in responding to applications. When the results of passing the stored procedure to the database are returned, the caching system can update the modification table to reflect the time of the new updates. Additionally, the results can be used to update the results table with new results for the stored procedure and the time these results were retrieved.
  • In one embodiment, the results table and/or dependency table can include an indication for each stored procedure entry whether that stored procedure modifies any data at the database. An embodiment that specifies whether each table in the dependency table is updated by the corresponding stored procedure or whether the stored procedure modifies the listed table has already been described. When the intermediary determines that a requested procedure contains a valid entry in the results table and the procedure does not modify data at the database, the cached results are returned and the stored procedure is not passed to the database. If the entry indicates that the stored procedure does modify data, it can be passed to the database to modify database data after returning the cached results to the requesting application. In yet another embodiment, a caching system is implemented to only cache stored procedure results and other information for procedures that do not modify data at the database.
  • Row-Level Caching and Invalidation
  • The embodiments described thus far have described table based caching systems that invalidate entries when a dependent table of a query is modified. The disclosed techniques are extendable to other levels of invalidation based on more refined analysis of modified data. For example, the disclosed technology can be used to invalidate cached query results when a row the query is dependent upon is modified. Likewise, results can be invalidated only when an actual entry in the database the query is dependent upon is modified. These techniques can increase efficiency and performance by further reducing the number of times valid query results in the cache are invalidated.
  • FIG. 10 is a flowchart depicting a row-based caching and invalidation technique in accordance with one embodiment. In FIG. 10, row based caching is implemented for queries whose dependencies are limited to the retrieval of records (row of data) based on a unique identifier for the row. For example, if a query specifies “select * from employee where user_id=1111”, and user_id is a unique user_id assigned to each individual in the organization, such a query can be cached and invalidated in accordance with the disclosed techniques. An update to the individual record (row) of the employee table specified in the query can be the basis for invalidating the cached query results. If an update is made to another record (row) in the employee table, the cached results are not invalidated since the update does not affect the cached results.
  • For queries that depend on something more than a unique record identifier, the table-based caching techniques previously described are employed. Consider an exemplary query that specifies, “select * from employee where salary >100000.” The results of this query depend upon a column in the employee table other than the unique record identifier for that row (e.g., user_id or social security number). The query is not merely dependent upon a part of the entry that is unique for each individual record, but rather the salary of an employee which is a non-unique portion of a record. If the results for this query are cached and a subsequent update increases the salary of an employee that was previously below $100,000 to above $100,000, the cached results will no longer be valid. The employee record with the salary column updated to a value above $100,000 should now be included in the query results. However, the update does not affect any rows that were returned in response to the original query. If invalidation is based only on changes to those records or rows included in the original results, row-based caching in this example would fail to properly invalidate the cached results and invalid results returned for a subsequent received version of this query.
  • In FIG. 10, selective row-based caching is implemented to guarantee accurate cache results while also improving performance by reducing the number of invalidations inherent in a table-based invalidation implementation. A query is received from a requesting application at step 802 and at 804, it is determined whether an entry corresponding to the received query exists in a results table. If there is no corresponding entry in the results table, the query is abstracted at step 806 and a determination made at step 808 as to whether an entry for the abstracted query skeleton exists in a dependency table.
  • If no entry exists for the query skeleton, the resulting skeleton is passed to the database at step 810 by calling a native analysis facility of the database to assess how the query structure is handled. The results of the analysis are accessed at step 812. At step 814, an entry is created in the dependency table for the query skeleton. Dependency tables in the row-based technique depicted in FIG. 10 are implemented as previously described with respect to table-based caching. The entry lists the abstracted query skeleton and any tables queries having that structure are dependent upon.
  • At step 816, it is determined whether the query requests records based solely on a unique identifier for individual records of the corresponding table. If the query depends solely on a unique identifier for a row of the relevant table, the process continues at step 818 where it is determined if the query is a write or read query. If the query is a read query, the query is modified at step 820 to include a request for the row ID number of the record requested by the query. Each record in a table includes an internal identifier used by the database to uniquely identify every record. This identifier or row ID number is different than the unique user data identifier referred to previously.
  • The modified query is passed to the database at step 822. The results of the query are received from the database at step 824. The query results are used to create an entry in results table 204 at step 826. The entry created in table 204 will not only include the query, the results, and the time the results were obtained, but also the row ID number associated with that query that was retrieved via the modified query. The row ID number is used to determine whether cached query results are valid when subsequent requests including the cached query are received. The query results are returned to the requesting application at step 828. If the cached system determines at step 818 that the query is a write query, a modification table is updated at step 830 to indicate the modifications to the tables effected by the write query. To facilitate the row-based caching technique of FIG. 10, the modification table stores an indication of the times rows within a table were last updated. At step 830, the modification table is updated to include the table dependencies determined at step 812. For each entry, the modification will specify the row_id for the specific record(s) modified by the query as well as the table that was modified and the time of modification. If it is determined at step 816 that the query does not requests records based solely on a unique identifier for individual records of the corresponding table, the method continues at step 832 where table based caching is instituted according to steps 320-332 of FIG. 4. Steps 322 and 328 are skipped if the query's structure is already cached.
  • If it is determined at step 804 that an entry exists in results table 204 for the query received at step 802, the dependencies for the query are determined at step 834. The tables the query is dependent upon are determined from dependency table 206. The row_id number of the query is determined from results table 204 at step 836. Modification table 208 is then searched at step 838 for an entry matching the dependent table of the query and the row_id number of the query. If an entry is found and the time of last modification to the specified row was before the results stored in table 204 were obtained, the cached results are determined to be valid at step 840. The cached results are returned to the requesting application at step 842. If no entry is found, it is determined that the cached results are valid and they are returned at step 842. If an entry is found and it indicates an update to the row after the results were obtained, the query is passed to the database at step 844 and the results received. The results are provided to the requesting application at step 846.
  • It should be noted that row-based caching and table-based caching can be contemporaneously implemented in accordance with one embodiment. For example, table 208 may only list table identifications for certain entries along with the time the table was modified when the entry is for a query that is dependent on something other than a unique record identifier. Table 208 may also include entries including row ID numbers and table IDs for other entries. Likewise, entries in table 204 for the query results may list the row_id numbers for queries meeting the unique row identifier dependency limitation. For more complicated queries with additional dependencies, only the results and time will be maintained. In this manner, when a query is received that has an entry in table 204, an intermediary can determine the row ID dependency from table 206 in order to compare that dependency with the time of last update from table 208 to determine whether the results in table 204 are valid.
  • In one embodiment, a caching system can be distributed across one or more servers or other systems at various levels to provide further performance and availability. FIG. 11 depicts an exemplary embodiment including caching intermediaries 108 distributed at application servers 102 as well as a central server 902. Central server 902 is implemented between application servers 102 and database server 122 to provide an additional level of caching.
  • Each application server includes a caching intermediary 108 as previously described. Central server 902 also includes a caching intermediary 108, providing a centralized cache for results and invalidation information that can be used by the individual intermediaries at each application server. In FIG. 11, the caching intermediary 108 at the central server includes similar cache 110 and interface 112 components as the local caching intermediaries. These components may include additional operations and perform slightly different operations in such a multi-level environment. Again, different implementations of intermediary 108 can be made in accordance with embodiments. In FIG. 11, the listener component 128 interfaces with the caching intermediary 108 at the central server 902 to provide information regarding updates to the database. The intermediary at the central server can maintain this information for invalidating cache entries. In one embodiment, the central server intermediary can pass this information to the local intermediaries at the application servers so it can be used there for invalidations. In yet another embodiment, the listener component 128 can interface directly with each caching intermediary 108 at the application server level and central server level.
  • In an exemplary operation of the system of FIG. 11, an application 104 at any of the application servers can issue a query or stored procedure call which is intercepted at the local caching intermediary 108 associated with that application. The caching intermediary can determine if it is storing dependency information for the structure of the received query. If the structure is stored locally, the local intermediary can determine if it is storing valid results for the received query as previously described. If the local intermediary is storing valid results, it can further access the central server's intermediary 108 to assess the validity of the results.
  • An application at one of the other application servers in communication with the central server may update database 120 in a transaction not seen at the local intermediary processing the current request. However, a query received from any of the local application servers will pass through central server 902. Accordingly, the local intermediary can access the central server to determine the last time any table, row, etc. upon which the received query is dependent was last modified by any of the applications at any of the application servers. If the local intermediary determines that its local results are valid, those results can be returned to the requesting application. If the local results are not valid, the local intermediary passes the query to the caching intermediary at the central server 902. The caching intermediary at central server 902 will return its locally cached results if they are valid.
  • If neither the local intermediary nor the central intermediary are maintaining valid results for the query, the intermediary at the central server will forward the query to the database and receive results. The intermediary at the central server will update its cache with the new results, time of retrieval, and/or any portions of the database modified by the query if necessary. The results will be returned to the local intermediary which will also update its cache in accordance with the new results, time, etc.
  • In one embodiment, the central server's caching intermediary can also send the results and any update information to the local intermediaries at the application servers in response to updates to the database from any of the application servers and/or in response to a direct update detected by listener component 128. In this manner, the local intermediaries need only check their local caches to determine if their cached results are still valid.
  • If the local intermediary receiving the query initially determines that it is not storing dependency information for the structure of the received query, it can abstract the query and pass it to the intermediary at the central server to determine if the intermediary at the central server is maintaining the dependency information. For example, dependency analysis may have already been performed by the database for the received structure in response to a query from another application server. If the intermediary at the central server is maintaining the information, it can pass it to the local intermediary which can cache the information for later use. Upon receiving the dependency information in one embodiment, the local intermediary determines that it is not storing valid results for the query and forwards the query to the central server's intermediary. In other embodiments, the local intermediary can pass the query to the central server's intermediary as soon as it determines that it is not storing the dependency information, rather than wait to receive this information.
  • If the database is not storing the dependency information for a query of this structure, it will send a response to the local intermediary informing it that the query structure has not yet been analyzed or that queries of that structure are not cacheable. In one embodiment, the central server intermediary stores information to indicate query structures that were previously determined to not be cacheable to avoid the performance of dependency analysis more than once for the same structure. Additionally, the local intermediaries can maintain information about query structures that were previously determined to not be cacheable so that a request to the central server can be avoided when it is known that queries of the received structure are not cacheable.
  • After receiving a notification from the central server intermediary that the dependency information is not being stored or that queries of the received query's structure are not cacheable, the local intermediary sends the actual query to the intermediary at the central server. The local intermediary also sends the actual query to the intermediary after receiving dependency information and determining that it is not maintaining valid results for the actual query as mentioned above. The central server intermediary can again check whether it is storing dependency information for the received query. In other embodiments, the central server intermediary only performs this check once. The central server intermediary will pass the abstracted query to the database by calling a facility such as “EXPLAIN PLAN” as previously described. The intermediary at the central server will also pass the actual query to the database. When the actual query results are received, the intermediary at the central server can cache the results and forward them to the local caching intermediary which will also cache the results. Likewise, when the results of the dependency analysis are received, the central server intermediary will cache the dependency information, etc. and forward the results to the local intermediary which will cache them as well. In one embodiment, the central server intermediary and local intermediaries wait to receive the dependency analysis information before caching query results or dependency information.
  • In FIG. 11, a dual-level caching system is provided with caches at the application server level and another server level implemented between the application servers and database server. In one embodiment, additional levels of caching can be used. For example, application server caching systems may interface with a regional server running a caching system in accordance with an embodiment. Multiple regional servers may interface with a central server running a caching system that interfaces with the database system. Other variations with additional levels of caching or further distribution of components across these servers can be implemented in accordance with various embodiments.
  • While exemplary embodiments have been described in which caching systems or intermediaries execute on application servers and other servers, any type of processing or computing device may be used, including personal computers, minicomputers, mainframes, handheld computing devices, mobile computing devices, and so forth. Typically, these computing devices will include one or more processors in communication with one or more processor readable storage devices, communication interfaces, peripheral devices, and so forth. Examples of storage devices include RAM, ROM, hard disk drives, floppy disk drives, CD ROMS, DVDs, flash memory, and so forth. Examples of peripherals include printers, monitors, keyboards, pointing devices, and so forth. Examples of communication interfaces include network cards, modems, wireless transmitters/receivers, and so forth. In some embodiments, all or part of the functionality is implemented in software, including firmware and/or micro code, that is stored on one or more processor readable storage devices and is used to program one or more processors to achieve the functionality described herein.
  • The foregoing detailed description has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure and any claimed subject matter to the precise form disclosed. Many modifications and variations are possible in light of the above teachings. The described embodiments were chosen in order to best explain the principles of the technology and its practical application to thereby enable others skilled in the art to best utilize the technology in various embodiments and with various modifications as are suited to the particular use contemplated. It is intended that the scope of the present disclosure and its claimed subject matter be defined by the claims appended hereto.

Claims (19)

1. A method of caching database query results, comprising:
receiving a request for information from a database;
determining if previously received results for said request are maintained locally;
if previously received results are not maintained locally for said request:
passing a form of said request to said database by calling a native analysis facility at said database to assess how said database processes requests of said form;
accessing results of said assessment by said native analysis facility;
determining from said results one or more dependencies of said database for requests of said form;
maintaining data indicating that requests of said form for said database include said one or more dependencies;
passing said request to said database and receiving results; and
maintaining information including said request and said results of said request.
2. The method of claim 1, wherein:
maintaining said information includes maintaining an indication of a time said results were determined.
3. The method of claim 2, further comprising:
if previously received results are being maintained for said request:
accessing said data to determine said one or more dependencies;
accessing information indicating a time of last update to said one or more dependencies;
determining whether said previously received results are valid by comparing said indication of said time said results were determined with said time of last update to said one or more dependencies;
returning said results in response to said request if said previously received results are valid.
4. The method of claim 3, further comprising:
if said previously received results are determined to be invalid:
passing said request to said database and receiving updated results;
updating said information maintained for said request to indicate said updated results.
5. The method of claim 1, wherein:
said native analysis facility is “EXPLAIN PLAN.”
6. The method of claim 1, wherein:
said native analysis facility is a debugging facility provided by said database.
7. The method of claim 1, wherein:
said native analysis facility is a performance analysis facility provided by said database.
8. The method of claim 1, wherein:
said one or more dependencies of said database for requests of said form are one or more tables of said database upon which requests of said form depend for results.
9. The method of claim 1, wherein:
said one or more dependencies of said database for requests of said form are one or more rows of one or more tables of said database upon which requests of said form depend for results.
10. The method of claim 1, further comprising, if previously received results are not being maintained for said request:
abstracting said request by removing any literal expressions included therein to generate said form of said request;
wherein said request is a database query and said form of said request is a skeleton of said database query.
11. The method of claim 1, wherein:
receiving said request includes receiving said request at a first caching system;
passing said form of said request includes passing said form of said request from a second caching system to said database after receiving at least one of said request and said request at said second caching system from said first caching system; and
maintaining said data and maintaining said information include maintaining said data and said information at said second caching system.
12. The method of claim 11, wherein:
maintaining said data and maintaining said information include maintaining said data and information at said first caching system and said second caching system.
13. A database caching system, comprising:
a database including a native analysis facility to analyze query structures;
a caching intermediary in communication with said database and an application accessing said database, said caching intermediary maintains one or more queries and results received from said database in response to said one or more queries, said caching intermediary receives a first query from said application and determines if said first query and previously received results for said first query are maintained by said caching intermediary, said caching intermediary passes a form of said first query to said native analysis facility at said database if said caching intermediary is not maintaining results for said first query and accesses results of said analysis facility to determine one or more tables of said database upon which queries of said form depend, said caching intermediary further maintains said form of said first query and an indication of said one of more tables of said database upon which queries of said form depend.
14. The database caching system of claim 13, wherein:
said caching intermediary maintains an indication of dependencies from said database and a time of last modification of each of said dependencies;
said caching intermediary receives a second query from said application and after determining that said second query is not maintained at said caching intermediary, passes a form of said second query to said native analysis facility and accesses results of said analysis facility to determine if said second query reads or modifies data at said database, said caching intermediary determines from said results one or more tables of said database modified by queries of said form of said second query if said second query updates data at said database, said caching intermediary passes said second query to said database and receives results in return, said caching intermediary maintains said second query with an indication of said results of said second query and also maintains an indication of said one or more tables of said database modified by queries of said form of said second query with an indication of a time of most recent modification to said one or more tables.
15. The database caching system of claim 14, wherein:
said caching intermediary maintains said form of said second query with an indication of said one or more tables modified by queries of said form of said second query.
16. The database caching system of claim 13, wherein:
said form of said first query is a structure of said first query generated by removing any literal expressions from said first query.
17. The database caching system of claim 13, wherein:
said caching intermediary includes a first caching intermediary at a first processing system and a second caching intermediary at a second processing system.
18. The database caching system of claim 17, wherein:
said caching intermediary further includes one or more additional caching intermediaries;
said second caching intermediary receives queries received at said first caching intermediary and said one or more additional caching intermediaries.
19. One or more processor readable storage devices having processor readable code embodied on said one or more processor readable storage devices, said processor readable code for programming one or more processors to perform a method comprising:
receiving a request for information from a database;
determining if previously received results for said request are maintained locally; and
if previously received results are not maintained locally for said request:
passing a form of said request to said database by calling a native analysis facility at said database to assess how said database processes requests of said form;
accessing results of said assessment by said native analysis facility;
determining from said results one or more dependencies of said database for requests of said form;
maintaining data indicating that requests of said form for said database include said one or more dependencies;
passing said request to said database and receiving results; and
maintaining information including said request and said results of said request.
US11/420,451 2005-05-25 2006-05-25 Database Caching and Invalidation using Database Provided Facilities for Query Dependency Analysis Abandoned US20060271510A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/420,451 US20060271510A1 (en) 2005-05-25 2006-05-25 Database Caching and Invalidation using Database Provided Facilities for Query Dependency Analysis

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US68461005P 2005-05-25 2005-05-25
US11/420,451 US20060271510A1 (en) 2005-05-25 2006-05-25 Database Caching and Invalidation using Database Provided Facilities for Query Dependency Analysis

Publications (1)

Publication Number Publication Date
US20060271510A1 true US20060271510A1 (en) 2006-11-30

Family

ID=37452936

Family Applications (10)

Application Number Title Priority Date Filing Date
US11/420,446 Active 2027-03-20 US7716377B2 (en) 2005-05-25 2006-05-25 Clustering server providing virtual machine data sharing
US11/441,676 Abandoned US20060271930A1 (en) 2005-05-25 2006-05-25 Clustered object state using synthetic transactions
US11/441,677 Abandoned US20060271931A1 (en) 2005-05-25 2006-05-25 Distributed signaling in a virtual machine cluster
US11/442,523 Abandoned US20070011667A1 (en) 2005-05-25 2006-05-25 Lock management for clustered virtual machines
US11/420,460 Abandoned US20060271557A1 (en) 2005-05-25 2006-05-25 Database Caching and Invalidation Based on Detected Database Updates
US11/420,466 Abandoned US20060271511A1 (en) 2005-05-25 2006-05-25 Database Caching and Invalidation for Stored Procedures
US11/441,605 Abandoned US20060271395A1 (en) 2005-05-25 2006-05-25 Distributed object identity in a virtual machine cluster
US11/442,522 Abandoned US20060271575A1 (en) 2005-05-25 2006-05-25 Clustered object state using field set operations
US11/442,524 Abandoned US20060271542A1 (en) 2005-05-25 2006-05-25 Clustered object state using logical actions
US11/420,451 Abandoned US20060271510A1 (en) 2005-05-25 2006-05-25 Database Caching and Invalidation using Database Provided Facilities for Query Dependency Analysis

Family Applications Before (9)

Application Number Title Priority Date Filing Date
US11/420,446 Active 2027-03-20 US7716377B2 (en) 2005-05-25 2006-05-25 Clustering server providing virtual machine data sharing
US11/441,676 Abandoned US20060271930A1 (en) 2005-05-25 2006-05-25 Clustered object state using synthetic transactions
US11/441,677 Abandoned US20060271931A1 (en) 2005-05-25 2006-05-25 Distributed signaling in a virtual machine cluster
US11/442,523 Abandoned US20070011667A1 (en) 2005-05-25 2006-05-25 Lock management for clustered virtual machines
US11/420,460 Abandoned US20060271557A1 (en) 2005-05-25 2006-05-25 Database Caching and Invalidation Based on Detected Database Updates
US11/420,466 Abandoned US20060271511A1 (en) 2005-05-25 2006-05-25 Database Caching and Invalidation for Stored Procedures
US11/441,605 Abandoned US20060271395A1 (en) 2005-05-25 2006-05-25 Distributed object identity in a virtual machine cluster
US11/442,522 Abandoned US20060271575A1 (en) 2005-05-25 2006-05-25 Clustered object state using field set operations
US11/442,524 Abandoned US20060271542A1 (en) 2005-05-25 2006-05-25 Clustered object state using logical actions

Country Status (2)

Country Link
US (10) US7716377B2 (en)
WO (2) WO2006128062A2 (en)

Cited By (109)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080098173A1 (en) * 2006-10-20 2008-04-24 Lakshminarayanan Chidambaran Consistent client-side cache
US20080098041A1 (en) * 2006-10-20 2008-04-24 Lakshminarayanan Chidambaran Server supporting a consistent client-side cache
US20090125496A1 (en) * 2007-11-13 2009-05-14 B-Hive Networks, Inc Network device and method for monitoring of backend transactions in data centers
US20090210459A1 (en) * 2008-02-19 2009-08-20 International Business Machines Corporation Document synchronization solution
US20090254589A1 (en) * 2008-04-07 2009-10-08 International Business Machines Corporation Client side caching of synchronized data
US20090300032A1 (en) * 2008-05-30 2009-12-03 Chirlian Peter J System, Method, and Computer Program Product for Modeling Changes to Large Scale Datasets
US20100161643A1 (en) * 2008-12-24 2010-06-24 Yahoo! Inc. Segmentation of interleaved query missions into query chains
US20110173947A1 (en) * 2010-01-19 2011-07-21 General Electric Company System and method for gas turbine power augmentation
US8326814B2 (en) 2007-12-05 2012-12-04 Box, Inc. Web-based file management system and service
US20130060795A1 (en) * 2011-09-07 2013-03-07 Unisys Corp. Prepared statements to improve performance in database interfaces
US20130124458A1 (en) * 2011-11-16 2013-05-16 Tomas Barreto Resource effective incremental updating of a remote client with events which occurred via a cloud-enabled platform
US8515902B2 (en) 2011-10-14 2013-08-20 Box, Inc. Automatic and semi-automatic tagging features of work items in a shared workspace for metadata tracking in a cloud-based content management system with selective or optional user contribution
US8719445B2 (en) 2012-07-03 2014-05-06 Box, Inc. System and method for load balancing multiple file transfer protocol (FTP) servers to service FTP connections for a cloud-based service
US8745267B2 (en) 2012-08-19 2014-06-03 Box, Inc. Enhancement of upload and/or download performance based on client and/or server feedback information
US8868574B2 (en) 2012-07-30 2014-10-21 Box, Inc. System and method for advanced search and filtering mechanisms for enterprise administrators in a cloud-based environment
US8892679B1 (en) 2013-09-13 2014-11-18 Box, Inc. Mobile device, methods and user interfaces thereof in a mobile device platform featuring multifunctional access and engagement in a collaborative environment provided by a cloud-based platform
US8914900B2 (en) 2012-05-23 2014-12-16 Box, Inc. Methods, architectures and security mechanisms for a third-party application to access content in a cloud-based platform
US20150032703A1 (en) * 2010-05-12 2015-01-29 Microsoft Corporation Getting dependency metadata using statement execution plans
US9015601B2 (en) 2011-06-21 2015-04-21 Box, Inc. Batch uploading of content to a web-based collaboration environment
US9019123B2 (en) 2011-12-22 2015-04-28 Box, Inc. Health check services for web-based collaboration environments
US9027108B2 (en) 2012-05-23 2015-05-05 Box, Inc. Systems and methods for secure file portability between mobile applications on a mobile device
US9054919B2 (en) 2012-04-05 2015-06-09 Box, Inc. Device pinning capability for enterprise cloud service and storage accounts
US9063912B2 (en) 2011-06-22 2015-06-23 Box, Inc. Multimedia content preview rendering in a cloud content management system
US9098474B2 (en) 2011-10-26 2015-08-04 Box, Inc. Preview pre-generation based on heuristics and algorithmic prediction/assessment of predicted user behavior for enhancement of user experience
US9117087B2 (en) 2012-09-06 2015-08-25 Box, Inc. System and method for creating a secure channel for inter-application communication based on intents
US9135462B2 (en) 2012-08-29 2015-09-15 Box, Inc. Upload and download streaming encryption to/from a cloud-based platform
US9195519B2 (en) 2012-09-06 2015-11-24 Box, Inc. Disabling the self-referential appearance of a mobile application in an intent via a background registration
US9197718B2 (en) 2011-09-23 2015-11-24 Box, Inc. Central management and control of user-contributed content in a web-based collaboration environment and management console thereof
US9195636B2 (en) 2012-03-07 2015-11-24 Box, Inc. Universal file type preview for mobile devices
US9213684B2 (en) 2013-09-13 2015-12-15 Box, Inc. System and method for rendering document in web browser or mobile device regardless of third-party plug-in software
US9237170B2 (en) 2012-07-19 2016-01-12 Box, Inc. Data loss prevention (DLP) methods and architectures by a cloud service
US9292833B2 (en) 2012-09-14 2016-03-22 Box, Inc. Batching notifications of activities that occur in a web-based collaboration environment
US9311071B2 (en) 2012-09-06 2016-04-12 Box, Inc. Force upgrade of a mobile application via a server side configuration file
US9369520B2 (en) 2012-08-19 2016-06-14 Box, Inc. Enhancement of upload and/or download performance based on client and/or server feedback information
US9396245B2 (en) 2013-01-02 2016-07-19 Box, Inc. Race condition handling in a system which incrementally updates clients with events that occurred in a cloud-based collaboration platform
US9413587B2 (en) 2012-05-02 2016-08-09 Box, Inc. System and method for a third-party application to access content within a cloud-based platform
US9483473B2 (en) 2013-09-13 2016-11-01 Box, Inc. High availability architecture for a cloud-based concurrent-access collaboration platform
US9495364B2 (en) 2012-10-04 2016-11-15 Box, Inc. Enhanced quick search features, low-barrier commenting/interactive features in a collaboration platform
WO2016183548A1 (en) * 2015-05-14 2016-11-17 Walleye Software, LLC Dynamic filter processing
US9507795B2 (en) 2013-01-11 2016-11-29 Box, Inc. Functionalities, features, and user interface of a synchronization client to a cloud-based environment
US9519886B2 (en) 2013-09-13 2016-12-13 Box, Inc. Simultaneous editing/accessing of content by collaborator invitation through a web-based or mobile application to a cloud-based collaboration platform
US9535924B2 (en) 2013-07-30 2017-01-03 Box, Inc. Scalability improvement in a system which incrementally updates clients with events that occurred in a cloud-based collaboration platform
US9535909B2 (en) 2013-09-13 2017-01-03 Box, Inc. Configurable event-based automation architecture for cloud-based collaboration platforms
US9553758B2 (en) 2012-09-18 2017-01-24 Box, Inc. Sandboxing individual applications to specific user folders in a cloud-based service
US9558202B2 (en) 2012-08-27 2017-01-31 Box, Inc. Server side techniques for reducing database workload in implementing selective subfolder synchronization in a cloud-based environment
US9575981B2 (en) 2012-04-11 2017-02-21 Box, Inc. Cloud service enabled to handle a set of files depicted to a user as a single file in a native operating system
US9602514B2 (en) 2014-06-16 2017-03-21 Box, Inc. Enterprise mobility management and verification of a managed application by a content provider
US9628268B2 (en) 2012-10-17 2017-04-18 Box, Inc. Remote key management in a cloud-based environment
US9633037B2 (en) 2013-06-13 2017-04-25 Box, Inc Systems and methods for synchronization event building and/or collapsing by a synchronization component of a cloud-based platform
US9652741B2 (en) 2011-07-08 2017-05-16 Box, Inc. Desktop application for access and interaction with workspaces in a cloud-based content management system and synchronization mechanisms thereof
US9665349B2 (en) 2012-10-05 2017-05-30 Box, Inc. System and method for generating embeddable widgets which enable access to a cloud-based collaboration platform
US9691051B2 (en) 2012-05-21 2017-06-27 Box, Inc. Security enhancement through application access control
US9705967B2 (en) 2012-10-04 2017-07-11 Box, Inc. Corporate user discovery and identification of recommended collaborators in a cloud platform
US9712510B2 (en) 2012-07-06 2017-07-18 Box, Inc. Systems and methods for securely submitting comments among users via external messaging applications in a cloud-based platform
US9756022B2 (en) 2014-08-29 2017-09-05 Box, Inc. Enhanced remote key management for an enterprise in a cloud-based environment
US9773051B2 (en) 2011-11-29 2017-09-26 Box, Inc. Mobile platform file and folder selection functionalities for offline access and synchronization
US9792320B2 (en) 2012-07-06 2017-10-17 Box, Inc. System and method for performing shard migration to support functions of a cloud-based service
US9794256B2 (en) 2012-07-30 2017-10-17 Box, Inc. System and method for advanced control tools for administrators in a cloud-based service
US9805050B2 (en) 2013-06-21 2017-10-31 Box, Inc. Maintaining and updating file system shadows on a local device by a synchronization client of a cloud-based platform
US9894119B2 (en) 2014-08-29 2018-02-13 Box, Inc. Configurable metadata-based automation and content classification architecture for cloud-based collaboration platforms
US9904435B2 (en) 2012-01-06 2018-02-27 Box, Inc. System and method for actionable event generation for task delegation and management via a discussion forum in a web-based collaboration environment
US9953036B2 (en) 2013-01-09 2018-04-24 Box, Inc. File system monitoring in a system which incrementally updates clients with events that occurred in a cloud-based collaboration platform
US9959420B2 (en) 2012-10-02 2018-05-01 Box, Inc. System and method for enhanced security and management mechanisms for enterprise administrators in a cloud-based environment
US9965745B2 (en) 2012-02-24 2018-05-08 Box, Inc. System and method for promoting enterprise adoption of a web-based collaboration environment
US9978040B2 (en) 2011-07-08 2018-05-22 Box, Inc. Collaboration sessions in a workspace on a cloud-based content management system
US10002154B1 (en) 2017-08-24 2018-06-19 Illumon Llc Computer data system data source having an update propagation graph with feedback cyclicality
CN108241647A (en) * 2016-12-23 2018-07-03 北京奇虎科技有限公司 Data processing and the method and apparatus of inquiry
US10038731B2 (en) 2014-08-29 2018-07-31 Box, Inc. Managing flow-based interactions with cloud-based shared content
CN108363741A (en) * 2018-01-22 2018-08-03 中国平安人寿保险股份有限公司 Big data unified interface method, apparatus, equipment and storage medium
US10110656B2 (en) 2013-06-25 2018-10-23 Box, Inc. Systems and methods for providing shell communication in a cloud-based platform
US10200256B2 (en) 2012-09-17 2019-02-05 Box, Inc. System and method of a manipulative handle in an interactive mobile user interface
US10229134B2 (en) 2013-06-25 2019-03-12 Box, Inc. Systems and methods for managing upgrades, migration of user data and improving performance of a cloud-based platform
US10235383B2 (en) 2012-12-19 2019-03-19 Box, Inc. Method and apparatus for synchronization of items with read-only permissions in a cloud-based environment
CN109710859A (en) * 2019-01-21 2019-05-03 北京字节跳动网络技术有限公司 Data query method and apparatus
US10452667B2 (en) 2012-07-06 2019-10-22 Box Inc. Identification of people as search results from key-word based searches of content in a cloud-based environment
US10509527B2 (en) 2013-09-13 2019-12-17 Box, Inc. Systems and methods for configuring event-based automation in cloud-based collaboration platforms
US10530854B2 (en) 2014-05-30 2020-01-07 Box, Inc. Synchronization of permissioned content in cloud-based environments
US10554426B2 (en) 2011-01-20 2020-02-04 Box, Inc. Real time notification of activities that occur in a web-based collaboration environment
US10574442B2 (en) 2014-08-29 2020-02-25 Box, Inc. Enhanced remote key management for an enterprise in a cloud-based environment
US10599671B2 (en) 2013-01-17 2020-03-24 Box, Inc. Conflict resolution, retry condition management, and handling of problem files for the synchronization client to a cloud-based platform
EP2118823B1 (en) * 2007-03-01 2020-04-15 Zipcar, Inc. Multi-tiered fleet management cache
CN111177161A (en) * 2019-11-07 2020-05-19 腾讯科技(深圳)有限公司 Data processing method and device, computing equipment and storage medium
US10706075B2 (en) * 2015-07-15 2020-07-07 International Business Machines Corporation Analyzing application behavior to determine relationships between data
US10725968B2 (en) 2013-05-10 2020-07-28 Box, Inc. Top down delete or unsynchronization on delete of and depiction of item synchronization with a synchronization client to a cloud-based platform
US10846074B2 (en) 2013-05-10 2020-11-24 Box, Inc. Identification and handling of items to be ignored for synchronization with a cloud-based platform by a synchronization client
US10860604B1 (en) * 2014-12-10 2020-12-08 Amazon Technologies, Inc. Scalable tracking for database udpates according to a secondary index
US10866931B2 (en) 2013-10-22 2020-12-15 Box, Inc. Desktop application for accessing a cloud collaboration platform
US10885036B2 (en) * 2015-02-03 2021-01-05 Red Hat, Inc. Obtaining incremental updates from a database using a partial query
US10915492B2 (en) 2012-09-19 2021-02-09 Box, Inc. Cloud-based platform enabled with media content indexed for text-based searches and/or metadata extraction
US10936559B1 (en) 2016-09-28 2021-03-02 Amazon Technologies, Inc. Strongly-consistent secondary index for a distributed data set
US11210610B2 (en) 2011-10-26 2021-12-28 Box, Inc. Enhanced multimedia content preview rendering in a cloud content management system
US11232481B2 (en) 2012-01-30 2022-01-25 Box, Inc. Extended applications of multimedia content previews in the cloud-based content management system
US11281484B2 (en) 2016-12-06 2022-03-22 Nutanix, Inc. Virtualized server systems and methods including scaling of file system virtual machines
US11314717B1 (en) 2017-06-23 2022-04-26 Amazon Technologies, Inc. Scalable architecture for propagating updates to replicated data
US11537384B2 (en) 2016-02-12 2022-12-27 Nutanix, Inc. Virtualized file server distribution across clusters
US11562034B2 (en) 2016-12-02 2023-01-24 Nutanix, Inc. Transparent referrals for distributed file servers
US11568073B2 (en) 2016-12-02 2023-01-31 Nutanix, Inc. Handling permissions for virtualized file servers
US11567934B2 (en) 2018-04-20 2023-01-31 Oracle International Corporation Consistent client-side caching for fine grained invalidations
CN115858408A (en) * 2022-12-29 2023-03-28 南京维拓科技股份有限公司 Method for transmitting design parameters in industrial design process
US11625373B2 (en) 2020-04-30 2023-04-11 International Business Machines Corporation Determining additions, deletions and updates to database tables
US11734276B2 (en) * 2016-12-29 2023-08-22 Beijing Qiyi Century Science & Technology Co., Ltd. Method and apparatus for updating search cache to improve the update speed of hot content
US11768809B2 (en) 2020-05-08 2023-09-26 Nutanix, Inc. Managing incremental snapshots for fast leader node bring-up
US11770447B2 (en) 2018-10-31 2023-09-26 Nutanix, Inc. Managing high-availability file servers
US11775397B2 (en) 2016-12-05 2023-10-03 Nutanix, Inc. Disaster recovery for distributed file servers, including metadata fixers
US11860892B2 (en) 2020-09-29 2024-01-02 Amazon Technologies, Inc. Offline index builds for database tables
US11880385B1 (en) 2020-09-29 2024-01-23 Amazon Technologies, Inc. Ordering updates to secondary indexes using conditional operations
US11888599B2 (en) 2016-05-20 2024-01-30 Nutanix, Inc. Scalable leadership election in a multi-processing computing environment
US11940990B1 (en) 2017-06-16 2024-03-26 Amazon Technologies, Inc. Global clock values for consistent queries to replicated data
US11947952B2 (en) 2022-07-15 2024-04-02 Nutanix, Inc. Virtualized file server disaster recovery

Families Citing this family (226)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8352400B2 (en) 1991-12-23 2013-01-08 Hoffberg Steven M Adaptive pattern recognition based controller apparatus and method and human-factored interface therefore
US7904187B2 (en) 1999-02-01 2011-03-08 Hoffberg Steven M Internet appliance system and method
GB0112781D0 (en) 2001-05-25 2001-07-18 Global Continuity Plc Method for rapid recovery from a network file server failure
US7529897B1 (en) 2003-12-31 2009-05-05 Vmware, Inc. Generating and using checkpoints in a virtual computer system
US9606821B2 (en) 2004-12-17 2017-03-28 Intel Corporation Virtual environment manager for creating and managing virtual machine environments
US7480822B1 (en) * 2005-07-13 2009-01-20 Symantec Corporation Recovery and operation of captured running states from multiple computing systems on a single computing system
US20070016628A1 (en) * 2005-07-14 2007-01-18 Lenevo (Singapore) Pte.Ltd. Classification system for versionable objects
US8166458B2 (en) * 2005-11-07 2012-04-24 Red Hat, Inc. Method and system for automated distributed software testing
US9135304B2 (en) * 2005-12-02 2015-09-15 Salesforce.Com, Inc. Methods and systems for optimizing text searches over structured data in a multi-tenant environment
US8402443B2 (en) * 2005-12-12 2013-03-19 dyna Trace software GmbH Method and system for automated analysis of the performance of remote method invocations in multi-tier applications using bytecode instrumentation
US7792875B2 (en) * 2006-03-30 2010-09-07 International Business Machines Corporation Method for representing and recreating object dependencies from one database system to another
US7757215B1 (en) * 2006-04-11 2010-07-13 Oracle America, Inc. Dynamic fault injection during code-testing using a dynamic tracing framework
US8286174B1 (en) 2006-04-17 2012-10-09 Vmware, Inc. Executing a multicomponent software application on a virtualized computer platform
US7797329B2 (en) * 2006-06-09 2010-09-14 Oracle America Inc. Method and system for enabling a synchronization-free and parallel commit phase
US7529827B2 (en) * 2006-06-29 2009-05-05 Stratavia Corporation Standard operating procedure automation in database administration
EP2485146B1 (en) * 2006-08-07 2021-03-17 Oracle International Corporation System and method for providing hardware virtualization in a virtual machine environment
US9231858B1 (en) 2006-08-11 2016-01-05 Dynatrace Software Gmbh Completeness detection of monitored globally distributed synchronous and asynchronous transactions
US8151277B2 (en) * 2007-05-15 2012-04-03 Dynatrace Software Gmbh Method and system for dynamic remote injection of in-process agents into virtual machine based applications
US8464225B2 (en) * 2007-05-06 2013-06-11 Dynatrace Software Gmbh Method and system for adaptive, generic code instrumentation using run-time or load-time generated inheritance information for diagnosis and monitoring application performance and failure
US8533687B1 (en) 2009-11-30 2013-09-10 dynaTrade Software GmbH Methods and system for global real-time transaction tracing
US7831620B2 (en) * 2006-08-31 2010-11-09 International Business Machines Corporation Managing execution of a query against a partitioned database
US8056141B2 (en) * 2006-09-13 2011-11-08 Imperva, Inc. Method for monitoring stored procedures
US20080098309A1 (en) * 2006-10-24 2008-04-24 Microsoft Corporation Managing virtual machines and hosts by property
US20080104588A1 (en) * 2006-10-27 2008-05-01 Barber Michael J Creation of temporary virtual machine clones of multiple operating systems
US8082344B2 (en) * 2007-02-12 2011-12-20 Microsoft Corporation Transaction manager virtualization
US8997048B1 (en) * 2007-02-14 2015-03-31 Oracle America, Inc. Method and apparatus for profiling a virtual machine
US20080243847A1 (en) * 2007-04-02 2008-10-02 Microsoft Corporation Separating central locking services from distributed data fulfillment services in a storage system
US8433693B2 (en) * 2007-04-02 2013-04-30 Microsoft Corporation Locking semantics for a storage system based on file types
US7853950B2 (en) 2007-04-05 2010-12-14 International Business Machines Corporarion Executing multiple threads in a processor
US9047412B2 (en) 2007-05-06 2015-06-02 Dynatrace Corporation System and method for extracting instrumentation relevant inheritance relationships for a distributed, inheritance rule based instrumentation system
US8336108B2 (en) 2007-06-22 2012-12-18 Red Hat, Inc. Method and system for collaboration involving enterprise nodes
US8191141B2 (en) 2007-06-22 2012-05-29 Red Hat, Inc. Method and system for cloaked observation and remediation of software attacks
US8949827B2 (en) * 2007-06-22 2015-02-03 Red Hat, Inc. Tracking a virtual machine
US9477572B2 (en) 2007-06-22 2016-10-25 Red Hat, Inc. Performing predictive modeling of virtual machine relationships
KR100911324B1 (en) * 2007-06-22 2009-08-07 삼성전자주식회사 Method for managing variability point and appratus therefor
US9678803B2 (en) 2007-06-22 2017-06-13 Red Hat, Inc. Migration of network entities to a cloud infrastructure
US8984504B2 (en) * 2007-06-22 2015-03-17 Red Hat, Inc. Method and system for determining a host machine by a virtual machine
US9354960B2 (en) 2010-12-27 2016-05-31 Red Hat, Inc. Assigning virtual machines to business application service groups based on ranking of the virtual machines
US8127290B2 (en) * 2007-06-22 2012-02-28 Red Hat, Inc. Method and system for direct insertion of a virtual machine driver
US8539570B2 (en) * 2007-06-22 2013-09-17 Red Hat, Inc. Method for managing a virtual machine
US9569330B2 (en) 2007-06-22 2017-02-14 Red Hat, Inc. Performing dependency analysis on nodes of a business application service group
US8429748B2 (en) * 2007-06-22 2013-04-23 Red Hat, Inc. Network traffic analysis using a dynamically updating ontological network description
US9727440B2 (en) 2007-06-22 2017-08-08 Red Hat, Inc. Automatic simulation of virtual machine performance
US9715438B2 (en) * 2007-06-29 2017-07-25 International Business Machines Corporation Static execution of statements in a program
US7941411B2 (en) * 2007-06-29 2011-05-10 Microsoft Corporation Memory transaction grouping
US8074094B2 (en) * 2007-06-30 2011-12-06 Cisco Technology, Inc. Session redundancy using a replay model
US7882198B2 (en) * 2007-07-02 2011-02-01 Oracle America, Inc. Shared JAVA JAR files
US8966488B2 (en) * 2007-07-06 2015-02-24 XMOS Ltd. Synchronising groups of threads with dedicated hardware logic
US8225315B1 (en) * 2007-07-23 2012-07-17 Oracle America, Inc. Virtual core management
US8799903B1 (en) * 2007-07-31 2014-08-05 Hewlett-Packard Development Company, L.P. Systems and methods for exchanging runtime functionalities between software stacks
US8458670B2 (en) * 2007-09-27 2013-06-04 Symantec Corporation Automatically adding bytecode to a software application to determine network communication information
US8245217B2 (en) * 2007-10-12 2012-08-14 Microsoft Corporation Management of software and operating system updates required for the process of creating a virtual machine facsimile of an existing physical or virtual machine
US8370370B2 (en) * 2007-10-15 2013-02-05 International Business Machines Corporation Bridging real-world web applications and 3D virtual worlds
CN101430687B (en) * 2007-11-09 2015-11-25 阿里巴巴集团控股有限公司 Based on statistical form application process and the system of OLTP environment
US8521966B2 (en) * 2007-11-16 2013-08-27 Vmware, Inc. VM inter-process communications
US8352911B2 (en) * 2007-11-21 2013-01-08 Teradata Us, Inc. Techniques for constructing and using run-time JAVA archives (JAR) for JAVA Stored Procedures (JSPS)
US8495486B2 (en) * 2007-12-21 2013-07-23 The Invention Science Fund I, Llc Look ahead of links/alter links
US8473836B2 (en) * 2007-12-21 2013-06-25 The Invention Science Fund I, Llc Look ahead of links/alter links
US8949977B2 (en) * 2007-12-21 2015-02-03 The Invention Science Fund I, Llc Look ahead of links/alter links
US20090165134A1 (en) * 2007-12-21 2009-06-25 Searete Llc, A Limited Liability Corporation Of The State Of Delaware Look ahead of links/alter links
US8468440B2 (en) * 2007-12-21 2013-06-18 The Invention Science Fund I, Llc Look ahead of links/alter links
US8489981B2 (en) * 2007-12-21 2013-07-16 The Invention Science Fund I, Llc Look ahead of links/alter links
US8793616B2 (en) 2007-12-21 2014-07-29 The Invention Science Fund I, Llc Look ahead of links/alter links
US8706796B2 (en) * 2007-12-27 2014-04-22 SAP France S.A. Managing a cluster of computers
US9600438B2 (en) * 2008-01-03 2017-03-21 Florida Institute For Human And Machine Cognition, Inc. Process integrated mechanism apparatus and program
US9116715B2 (en) * 2008-02-04 2015-08-25 Rightscale, Inc. Systems and methods for efficiently booting and configuring virtual servers
US8245236B2 (en) * 2008-02-27 2012-08-14 International Business Machines Corporation Lock based moving of threads in a shared processor partitioning environment
US20090240930A1 (en) * 2008-03-24 2009-09-24 International Business Machines Corporation Executing An Application On A Parallel Computer
US8646052B2 (en) * 2008-03-31 2014-02-04 Intel Corporation Method and apparatus for providing a secure display window inside the primary display
US9086924B2 (en) * 2008-04-24 2015-07-21 International Business Machines Corporation Executing a distributed java application on a plurality of compute nodes
US8185901B2 (en) 2008-04-24 2012-05-22 International Business Machines Corporation Parsing an application to find serial and parallel data segments to minimize migration overhead between serial and parallel compute nodes
US8281311B2 (en) * 2008-04-24 2012-10-02 International Business Machines Corporation Executing a distributed software application on a plurality of compute nodes according to a compilation history
US8161483B2 (en) 2008-04-24 2012-04-17 International Business Machines Corporation Configuring a parallel computer based on an interleave rate of an application containing serial and parallel segments
US20110131002A1 (en) * 2008-05-15 2011-06-02 Simeon Falk Sheye Method for automatic testing of software
US8375387B2 (en) * 2008-05-30 2013-02-12 Red Hat, Inc. Product independent orchestration tool
US8615758B2 (en) * 2008-05-30 2013-12-24 Red Hat, Inc. Combining system blueprints, functional layer, and software bits in parallel development of machines
US8561062B2 (en) * 2008-05-30 2013-10-15 Red Hat, Inc. Synchronizing changes made on self-replicated machines to the corresponding parent machines
US8516494B2 (en) * 2008-06-16 2013-08-20 International Business Machines Corporation Executing an application on a parallel computer
US9100246B1 (en) * 2008-06-19 2015-08-04 Symantec Corporation Distributed application virtualization
US9058420B2 (en) * 2008-06-20 2015-06-16 Vmware, Inc. Synchronous decoupled program analysis in virtual environments
US20100082702A1 (en) * 2008-09-29 2010-04-01 Honeywell International Inc. Dynamic vehicle information management
US8732716B2 (en) 2008-09-30 2014-05-20 International Business Machines Corporation Virtualization across physical partitions of a multi-core processor (MCP)
US8438404B2 (en) * 2008-09-30 2013-05-07 International Business Machines Corporation Main processing element for delegating virtualized control threads controlling clock speed and power consumption to groups of sub-processing elements in a system such that a group of sub-processing elements can be designated as pseudo main processing element
US8195707B1 (en) * 2008-09-30 2012-06-05 Adobe Systems Incorporated Identifying and reacting to changes in an extensible automatic runtime object management system
US20100088698A1 (en) * 2008-10-03 2010-04-08 Ravishankar Krishnamurthy Techniques for managing communication sessions
EP2352090B1 (en) * 2008-10-06 2019-09-25 International Business Machines Corporation System accessing shared data by a plurality of application servers
US8645922B2 (en) * 2008-11-25 2014-02-04 Sap Ag System and method of implementing a concurrency profiler
US20100153693A1 (en) * 2008-12-17 2010-06-17 Microsoft Corporation Code execution with automated domain switching
US9292557B2 (en) * 2009-02-27 2016-03-22 Red Hat Israel, Ltd. Managing virtual machines using hierarchical labeling
US8863093B1 (en) * 2009-03-06 2014-10-14 Coverity, Inc. Load-time instrumentation of virtual machine program code
US9104757B2 (en) * 2009-06-24 2015-08-11 Red Hat Israel, Ltd. Interactive search monitoring in a virtual machine environment
US20100332593A1 (en) * 2009-06-29 2010-12-30 Igor Barash Systems and methods for operating an anti-malware network on a cloud computing platform
JP5458708B2 (en) * 2009-07-09 2014-04-02 株式会社リコー Image processing apparatus, display control method, and display control program
US20110035802A1 (en) * 2009-08-07 2011-02-10 Microsoft Corporation Representing virtual object priority based on relationships
US9143597B2 (en) * 2009-09-21 2015-09-22 Avaya Inc. Method for telephony client synchronization in telephone virtualization
US9338273B2 (en) * 2009-09-22 2016-05-10 Avaya Inc. Method for telephony client synchronization in telephone virtualization
US8718611B2 (en) * 2009-09-30 2014-05-06 Avaya Inc. Method for the selection of an active software environment of a virtualized telecommunications terminal
US8407723B2 (en) * 2009-10-08 2013-03-26 Tibco Software, Inc. JAVA virtual machine having integrated transaction management system and facility to query managed objects
US8244682B2 (en) * 2009-10-23 2012-08-14 Clausal Computing Oy Saving snapshot of a knowledge base without blocking
US9094426B2 (en) 2009-11-20 2015-07-28 Avaya Inc. Method for telecommunications device synchronization
CN102073512B (en) 2009-11-23 2014-07-16 阿里巴巴集团控股有限公司 JAVA cluster application system code loading and upgrading device and method
US8352953B2 (en) * 2009-12-03 2013-01-08 International Business Machines Corporation Dynamically provisioning virtual machines
US8311032B2 (en) * 2009-12-03 2012-11-13 International Business Machines Corporation Dynamically provisioning virtual machines
WO2011075484A2 (en) 2009-12-14 2011-06-23 Citrix Systems, Inc. A secure virtualization environment bootable from an external media device
US8924571B2 (en) 2009-12-14 2014-12-30 Citrix Systems, Imc. Methods and systems for providing to virtual machines, via a designated wireless local area network driver, access to data associated with a connection to a wireless local area network
US20110173177A1 (en) * 2010-01-11 2011-07-14 Flavio Junqueira Sightful cache: efficient invalidation for search engine caching
US20120179778A1 (en) * 2010-01-22 2012-07-12 Brutesoft, Inc. Applying networking protocols to image file management
US8874914B2 (en) 2010-02-05 2014-10-28 Accenture Global Services Limited Secure and automated credential information transfer mechanism
US8407531B2 (en) * 2010-02-26 2013-03-26 Bmc Software, Inc. Method of collecting and correlating locking data to determine ultimate holders in real time
US8825962B1 (en) * 2010-04-20 2014-09-02 Facebook, Inc. Push-based cache invalidation notification
US8990802B1 (en) * 2010-05-24 2015-03-24 Thinking Software, Inc. Pinball virtual machine (PVM) implementing computing process within a structural space using PVM atoms and PVM atomic threads
US9075635B1 (en) * 2010-07-26 2015-07-07 Symantec Corporation Systems and methods for merging virtual layers
EP2447836A1 (en) * 2010-10-18 2012-05-02 Simulity Labs Ltd Multiple virtual machine engines on a single card
US8418185B2 (en) 2010-10-19 2013-04-09 International Business Machines Corporation Memory maximization in a high input/output virtual machine environment
US9075661B2 (en) 2010-10-20 2015-07-07 Microsoft Technology Licensing, Llc Placing objects on hosts using hard and soft constraints
US8296267B2 (en) 2010-10-20 2012-10-23 Microsoft Corporation Upgrade of highly available farm server groups
US8386501B2 (en) 2010-10-20 2013-02-26 Microsoft Corporation Dynamically splitting multi-tenant databases
US8751656B2 (en) 2010-10-20 2014-06-10 Microsoft Corporation Machine manager for deploying and managing machines
US8417737B2 (en) 2010-10-20 2013-04-09 Microsoft Corporation Online database availability during upgrade
US8799453B2 (en) 2010-10-20 2014-08-05 Microsoft Corporation Managing networks and machines for an online service
US8719402B2 (en) 2010-10-21 2014-05-06 Microsoft Corporation Goal state communication in computer clusters
US8910155B1 (en) * 2010-11-02 2014-12-09 Symantec Corporation Methods and systems for injecting endpoint management agents into virtual machines
US9141415B2 (en) * 2010-11-16 2015-09-22 Syddansk Universitet Method for dynamically transforming the bytecode of Java virtual machine bootstrap classes
US8887122B2 (en) 2010-11-23 2014-11-11 Red Hat, Inc. Find and track information of interface usage of software libraries by other software
US8850550B2 (en) 2010-11-23 2014-09-30 Microsoft Corporation Using cached security tokens in an online service
US8863108B2 (en) * 2010-11-23 2014-10-14 Red Hat, Inc. Finding out if software will run on an operating system without installing that software
US8776036B2 (en) * 2010-11-23 2014-07-08 Red Hat, Inc. Determining support criteria for shared libraries based on their priority levels
US8938706B2 (en) 2010-11-23 2015-01-20 Red Hat, Inc. Providing customized visualization of application binary interface/application programming interface-related information
US9032146B2 (en) 2010-11-30 2015-05-12 Lenovo Enterprise Solutions (Singapore) Pte. Ltd. Dynamic use of raid levels responsive to workload requirements
US20120137062A1 (en) * 2010-11-30 2012-05-31 International Business Machines Corporation Leveraging coalesced memory
US9721030B2 (en) 2010-12-09 2017-08-01 Microsoft Technology Licensing, Llc Codeless sharing of spreadsheet objects
WO2012091948A2 (en) 2010-12-28 2012-07-05 Citrix Systems, Inc. Systems and methods for database proxy request switching
US9589029B2 (en) * 2010-12-28 2017-03-07 Citrix Systems, Inc. Systems and methods for database proxy request switching
US8677356B2 (en) * 2011-01-11 2014-03-18 International Business Machines Corporation Adjunct partition work scheduling with quality of service attributes
KR101191727B1 (en) * 2011-02-28 2012-11-21 (주)지노게임즈 System and method for muulti-thread hadling using multi-virtual machine
US8990823B2 (en) 2011-03-10 2015-03-24 International Business Machines Corporation Optimizing virtual machine synchronization for application software
US9274919B2 (en) 2011-04-29 2016-03-01 Dynatrace Software Gmbh Transaction tracing mechanism of distributed heterogenous transactions having instrumented byte code with constant memory consumption and independent of instrumented method call depth
US9147195B2 (en) 2011-06-14 2015-09-29 Microsoft Technology Licensing, Llc Data custodian and curation system
US9244956B2 (en) 2011-06-14 2016-01-26 Microsoft Technology Licensing, Llc Recommending data enrichments
US9122720B2 (en) * 2011-06-14 2015-09-01 Microsoft Technology Licensing, Llc Enriching database query responses using data from external data sources
US8832690B1 (en) * 2011-06-21 2014-09-09 Google Inc. Multi-threaded virtual machine processing on a web page
US8719232B2 (en) * 2011-06-30 2014-05-06 Verisign, Inc. Systems and methods for data integrity checking
US8615503B2 (en) * 2011-07-01 2013-12-24 International Business Machines Corporation Method for attaching partition online to range partitioned table
US9176829B2 (en) * 2011-07-01 2015-11-03 Microsoft Technology Licensing, Llc Managing recovery virtual machines in clustered environment
US8914466B2 (en) 2011-07-07 2014-12-16 International Business Machines Corporation Multi-level adaptive caching within asset-based web systems
US9361162B1 (en) * 2011-08-26 2016-06-07 Amazon Technologies, Inc. Executing threads of an application across multiple computing devices in a distributed virtual machine environment
US20130074065A1 (en) * 2011-09-21 2013-03-21 Ibm Corporation Maintaining Consistency of Storage in a Mirrored Virtual Environment
DE102011116866A1 (en) * 2011-10-25 2013-04-25 Fujitsu Technology Solutions Intellectual Property Gmbh Cluster system and method for executing a plurality of virtual machines
CN103988177B (en) * 2011-12-12 2017-02-22 国际商业机器公司 Maintenance of offline virtual machines based on maintenance register
US20130152081A1 (en) * 2011-12-13 2013-06-13 International Business Machines Corporation Selectable event reporting for highly virtualized partitioned systems
US9317552B2 (en) * 2012-01-30 2016-04-19 Memsql, Inc. Reusing existing query plans in a database system
US9141678B2 (en) * 2012-01-30 2015-09-22 Memsql, Inc. Distributed query cache in a database system
KR101878297B1 (en) * 2012-03-06 2018-08-07 삼성전자주식회사 Method and apparatus for recovering lock holder preemption
US9251209B2 (en) 2012-03-15 2016-02-02 International Business Machines Corporation Autonomic caching for in memory data grid query processing
US8694961B2 (en) * 2012-04-03 2014-04-08 Microsoft Corporation Thread-agile execution of dynamic programming language programs
US8881149B2 (en) * 2012-04-11 2014-11-04 International Business Machines Corporation Control of java resource runtime usage
US9922133B2 (en) * 2012-04-16 2018-03-20 Entit Software Llc Live topological query
US20140012704A1 (en) 2012-07-05 2014-01-09 Google Inc. Selecting a preferred payment instrument based on a merchant category
US9152449B2 (en) 2012-07-13 2015-10-06 International Business Machines Corporation Co-location of virtual machines with nested virtualization
WO2014015486A1 (en) * 2012-07-25 2014-01-30 华为技术有限公司 Data shunting method, data transmission device and shunting node device
US8972971B2 (en) * 2012-08-09 2015-03-03 International Business Machines Corporation Image instance mapping
US20140129513A1 (en) * 2012-11-08 2014-05-08 Callidus Software Incorporated Subset calculation by identifying calculated values with modified parameters
US9183271B2 (en) * 2012-12-04 2015-11-10 Pivotal Software, Inc. Big-fast data connector between in-memory database system and data warehouse system
US9336024B1 (en) * 2012-12-27 2016-05-10 Google Inc. Clustering for parallel processing
US9092767B1 (en) 2013-03-04 2015-07-28 Google Inc. Selecting a preferred payment instrument
US9384037B2 (en) * 2013-03-14 2016-07-05 Intel Corporation Memory object reference count management with improved scalability
US9235618B2 (en) * 2013-04-06 2016-01-12 Citrix Systems, Inc. Systems and methods for caching of SQL responses using integrated caching
US9658899B2 (en) * 2013-06-10 2017-05-23 Amazon Technologies, Inc. Distributed lock management in a cloud computing environment
US9600514B2 (en) 2013-09-09 2017-03-21 VoltDB, Inc. Methods and systems for detecting data divergence and inconsistency across replicas of data within a shared-nothing distributed database
US10176240B2 (en) 2013-09-12 2019-01-08 VoltDB, Inc. Methods and systems for real-time transactional database transformation
US10303682B2 (en) * 2013-09-21 2019-05-28 Oracle International Corporation Automatic verification and triage of query results
US9515901B2 (en) 2013-10-18 2016-12-06 AppDynamics, Inc. Automatic asynchronous handoff identification
US9639544B1 (en) 2013-10-28 2017-05-02 Pivotal Software, Inc. Table data persistence
US9922043B1 (en) 2013-10-28 2018-03-20 Pivotal Software, Inc. Data management platform
US9274828B2 (en) 2013-11-03 2016-03-01 Maestrano Pty Ltd. Systems and methods for event driven object management and distribution among multiple client applications
US9594782B2 (en) * 2013-12-23 2017-03-14 Ic Manage, Inc. Hierarchical file block variant store apparatus and method of operation
US9639571B2 (en) 2013-12-30 2017-05-02 VoltDB, Inc. Methods and systems for increasing capacity and performing data rebalancing without downtime to a distributed shared-nothing database with serializable isolation
US9858572B2 (en) 2014-02-06 2018-01-02 Google Llc Dynamic alteration of track data
GB2524075A (en) * 2014-03-14 2015-09-16 Ibm Advanced result cache refill
US9703611B1 (en) 2014-03-21 2017-07-11 Amazon Technologies, Inc. Isolating resources for utilization by tenants executing in multi-tenant software containers
WO2015179509A1 (en) * 2014-05-21 2015-11-26 Georgia State University Research Foundation, Inc. High-performance computing framework for cloud computing environments
US10097410B2 (en) * 2014-06-26 2018-10-09 Vmware, Inc. Methods and apparatus to scale application deployments in cloud computing environments
US9369406B2 (en) * 2014-07-03 2016-06-14 Sas Institute Inc. Resource server providing a rapidly changing resource
US10200258B2 (en) * 2014-08-14 2019-02-05 Juniper Networks, Inc. Transaction integrity for network services configuration
CN105446792B (en) * 2014-08-27 2019-09-24 联想(北京)有限公司 A kind of dispositions method of virtual machine, deployment device and management node
US9535811B2 (en) 2014-10-31 2017-01-03 AppDynamics, Inc. Agent dynamic service
US9529691B2 (en) 2014-10-31 2016-12-27 AppDynamics, Inc. Monitoring and correlating a binary process in a distributed business transaction
US20160125029A1 (en) * 2014-10-31 2016-05-05 InsightSoftware.com International Intelligent caching for enterprise resource planning reporting
US9535666B2 (en) 2015-01-29 2017-01-03 AppDynamics, Inc. Dynamic agent delivery
WO2016144299A1 (en) * 2015-03-06 2016-09-15 Hewlett Packard Enterprise Development Lp Graph update flush to a shared memory
US9934277B2 (en) 2015-05-19 2018-04-03 International Business Machines Corporation Data management system with stored procedures
US20160364667A1 (en) * 2015-06-15 2016-12-15 Microsoft Technology Licensing, Llc Providing dynamically responsive availability view
US10248691B2 (en) * 2015-07-13 2019-04-02 Paypal, Inc. Read/write split database query routing
US10846115B1 (en) * 2015-08-10 2020-11-24 Amazon Technologies, Inc. Techniques for managing virtual instance data in multitenant environments
CN106980625B (en) * 2016-01-18 2020-08-04 阿里巴巴集团控股有限公司 Data synchronization method, device and system
US10216926B2 (en) * 2016-01-29 2019-02-26 Cisco Technology, Inc. Isolation of untrusted code in operating system without isolation capability
US10503508B2 (en) * 2016-10-06 2019-12-10 Sisense Ltd. Predictive query execution in analytical databases
CN106648909A (en) 2016-10-13 2017-05-10 华为技术有限公司 Management method and device for dish lock and system
US10666443B2 (en) * 2016-10-18 2020-05-26 Red Hat, Inc. Continued verification and monitoring of application code in containerized execution environment
US10474554B2 (en) * 2016-11-18 2019-11-12 Vmware, Inc. Immutable file storage
WO2018120171A1 (en) * 2016-12-30 2018-07-05 华为技术有限公司 Method, device and system for executing stored procedure
US10200876B2 (en) * 2017-01-17 2019-02-05 Argela Yazilim ve Bilisim Teknolojileri San. ve Tic. A.S. Method and system for a wireless access transmission network across intersecting electromagnetically shielded regions
US20180225325A1 (en) * 2017-02-07 2018-08-09 International Business Machines Corporation Application resiliency management using a database driver
US11070647B1 (en) * 2017-03-14 2021-07-20 Parallels International Gmbh Seamless cross-platform synchronization of user activities and application data between mobile and desktop devices
JP6936604B2 (en) * 2017-03-31 2021-09-15 日立金属株式会社 Composite cable
CN107577516B (en) * 2017-07-28 2020-08-14 华为技术有限公司 Virtual machine password resetting method, device and system
CN107562961A (en) * 2017-10-09 2018-01-09 郑州云海信息技术有限公司 A kind of centralized management method and apparatus of mysql databases
US11474849B2 (en) * 2018-01-29 2022-10-18 Walmart Apollo, Llc Distribution of applications among machines in a cloud
WO2019193386A1 (en) * 2018-04-03 2019-10-10 Pratik Sharma Highly available data zones
US11086826B2 (en) 2018-04-30 2021-08-10 Nutanix, Inc. Virtualized server systems and methods including domain joining techniques
US10862252B2 (en) * 2018-05-04 2020-12-08 The Ricker Lyman Robotic Company, Inc. Surface-contact ethernet connector, network equipment chassis including the same and operating method thereof
JP6963534B2 (en) 2018-05-25 2021-11-10 ルネサスエレクトロニクス株式会社 Memory protection circuit and memory protection method
CN109446448A (en) * 2018-09-10 2019-03-08 平安科技(深圳)有限公司 Data processing method and system
JP7031569B2 (en) * 2018-11-29 2022-03-08 日本電信電話株式会社 Information creation device, information creation method, and information creation program
RU2724801C1 (en) * 2019-02-07 2020-06-25 Акционерное общество "Лаборатория Касперского" Method of balancing load on virtual protection machines, provided that selection area of virtual protection machines
CN109933411B (en) * 2019-03-31 2021-03-30 山东超越数控电子股份有限公司 System and method for modifying internal configuration of virtual machine on line
CN110266799B (en) * 2019-06-21 2022-07-05 国网山西省电力公司忻州供电公司 Method for realizing idempotency based on cache
US11494374B2 (en) * 2019-07-15 2022-11-08 Amadeus S.A.S., Sophia Antipolis Processing database requests
FR3099598B1 (en) 2019-07-31 2021-08-27 Amadeus DISTRIBUTED AUTOMATIC LEARNING FOR THE VALIDITY OF ANTI-STORED DATA
CN110807040B (en) * 2019-10-30 2023-03-24 北京达佳互联信息技术有限公司 Method, device, equipment and storage medium for managing data
US11288212B2 (en) * 2019-12-18 2022-03-29 Samsung Electronics Co., Ltd. System, apparatus, and method for secure deduplication
US11386119B2 (en) * 2020-01-31 2022-07-12 EMC IP Holding Company LLC System and method for data orchestration for non-relational databases and key-value storage in multiple computing environments
US11301517B2 (en) 2020-05-07 2022-04-12 Ebay Inc. Method and system for identifying, managing, and monitoring data dependencies
US20220035685A1 (en) * 2020-08-03 2022-02-03 Juniper Networks, Inc. Device access control for applications of multiple containers
US11741093B1 (en) 2021-07-21 2023-08-29 T-Mobile Usa, Inc. Intermediate communication layer to translate a request between a user of a database and the database
US20230119503A1 (en) * 2021-10-18 2023-04-20 Sophos Limited Network configuration update

Citations (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5920725A (en) * 1997-07-02 1999-07-06 Adaptivity Inc. Run-time object-synthesis and transparent client/server updating of distributed objects using a meta server of all object descriptors
US5987254A (en) * 1997-07-14 1999-11-16 Hewlett Packard Company System-wide memoization of array dependence information
US5999946A (en) * 1996-04-10 1999-12-07 Harris Corporation Databases in telecommunications
US6009271A (en) * 1996-10-28 1999-12-28 Bmc Software, Inc. Method of retrieving data from a relational database
US6016512A (en) * 1997-11-20 2000-01-18 Telcordia Technologies, Inc. Enhanced domain name service using a most frequently used domain names table and a validity code table
US6347312B1 (en) * 1998-11-05 2002-02-12 International Business Machines Corporation Lightweight directory access protocol (LDAP) directory server cache mechanism and method
US20020087798A1 (en) * 2000-11-15 2002-07-04 Vijayakumar Perincherry System and method for adaptive data caching
US20020107835A1 (en) * 2001-02-08 2002-08-08 Coram Michael T. System and method for adaptive result set caching
US6457020B1 (en) * 2000-03-20 2002-09-24 International Business Machines Corporation Query optimization using a multi-layered object cache
US6636853B1 (en) * 1999-08-30 2003-10-21 Morphism, Llc Method and apparatus for representing and navigating search results
US20030204517A1 (en) * 1998-05-29 2003-10-30 Brian Skinner Method and apparatus of performing active update notification
US6654766B1 (en) * 2000-04-04 2003-11-25 International Business Machines Corporation System and method for caching sets of objects
US6725333B1 (en) * 1999-04-22 2004-04-20 International Business Machines Corporation System and method for managing cachable entities
US20040193656A1 (en) * 2003-03-28 2004-09-30 Pizzo Michael J. Systems and methods for caching and invalidating database results and derived objects
US20040205092A1 (en) * 2003-03-27 2004-10-14 Alan Longo Data storage and caching architecture
US6834290B1 (en) * 1999-11-15 2004-12-21 Quest Software, Inc. System and method for developing a cost-effective reorganization plan for data reorganization
US6871780B2 (en) * 2000-11-27 2005-03-29 Airclic, Inc. Scalable distributed database system and method for linking codes to internet information
US20060026154A1 (en) * 2004-07-30 2006-02-02 Mehmet Altinel System and method for adaptive database caching
US7065538B2 (en) * 2000-02-11 2006-06-20 Quest Software, Inc. System and method for reconciling transactions between a replication system and a recovered database
US7162467B2 (en) * 2001-02-22 2007-01-09 Greenplum, Inc. Systems and methods for managing distributed database resources

Family Cites Families (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5062037A (en) * 1988-10-24 1991-10-29 Ibm Corp. Method to provide concurrent execution of distributed application programs by a host computer and an intelligent work station on an sna network
US5319773A (en) * 1990-05-16 1994-06-07 International Business Machines Corporation Asynchronous resynchronization of a commit procedure
US5666514A (en) * 1994-07-01 1997-09-09 Board Of Trustees Of The Leland Stanford Junior University Cache memory containing extra status bits to indicate memory regions where logging of data should occur
DE69713400T2 (en) * 1996-01-24 2002-10-31 Sun Microsystems Inc Processor with area check for matrix access
US6456893B1 (en) * 1996-11-26 2002-09-24 Shikoku Electric Power Company, Inc. Apparatus management system
US5953736A (en) * 1997-04-23 1999-09-14 Sun Microsystems, Inc. Write barrier system and method including pointer-specific instruction variant replacement mechanism
US5845298A (en) * 1997-04-23 1998-12-01 Sun Microsystems, Inc. Write barrier system and method for trapping garbage collection page boundary crossing pointer stores
US6003065A (en) * 1997-04-24 1999-12-14 Sun Microsystems, Inc. Method and system for distributed processing of applications on host and peripheral devices
US6330659B1 (en) * 1997-11-06 2001-12-11 Iready Corporation Hardware accelerator for an object-oriented programming language
US5873104A (en) * 1997-06-26 1999-02-16 Sun Microsystems, Inc. Bounded-pause time garbage collection system and method including write barrier associated with source and target instances of a partially relocated object
US5857210A (en) * 1997-06-26 1999-01-05 Sun Microsystems, Inc. Bounded-pause time garbage collection system and method including read and write barriers associated with an instance of a partially relocated object
US6226734B1 (en) * 1998-06-10 2001-05-01 Compaq Computer Corporation Method and apparatus for processor migration from different processor states in a multi-processor computer system
US6243825B1 (en) * 1998-04-17 2001-06-05 Microsoft Corporation Method and system for transparently failing over a computer name in a server cluster
US6385643B1 (en) * 1998-11-05 2002-05-07 Bea Systems, Inc. Clustered enterprise Java™ having a message passing kernel in a distributed processing system
GB9825102D0 (en) * 1998-11-16 1999-01-13 Insignia Solutions Plc Computer system
JP3792419B2 (en) * 1998-11-27 2006-07-05 株式会社日立製作所 Directory data conversion method, storage medium storing directory data conversion program, and directory conversion server
US6718457B2 (en) * 1998-12-03 2004-04-06 Sun Microsystems, Inc. Multiple-thread processor for threaded software applications
US6138143A (en) * 1999-01-28 2000-10-24 Genrad, Inc. Method and apparatus for asynchronous transaction processing
US6327594B1 (en) * 1999-01-29 2001-12-04 International Business Machines Corporation Methods for shared data management in a pervasive computing environment
US7013454B2 (en) * 1999-02-22 2006-03-14 Sun Microsystems, Inc. Thread suspension system and method using trapping instructions
US6799202B1 (en) * 1999-12-16 2004-09-28 Hachiro Kawaii Federated operating system for a server
US6496917B1 (en) * 2000-02-07 2002-12-17 Sun Microsystems, Inc. Method to reduce memory latencies by performing two levels of speculation
US6591278B1 (en) * 2000-03-03 2003-07-08 R-Objects, Inc. Project data management system and method
WO2001067238A1 (en) * 2000-03-08 2001-09-13 Sun Microsystems, Inc. Processing architecture having an array bounds check capability
US6618737B2 (en) * 2000-03-09 2003-09-09 International Business Machines Corporation Speculative caching of individual fields in a distributed object system
US6826757B2 (en) * 2000-04-18 2004-11-30 Sun Microsystems, Inc. Lock-free implementation of concurrent shared object with dynamic node allocation and distinguishing pointer value
US6408383B1 (en) * 2000-05-04 2002-06-18 Sun Microsystems, Inc. Array access boundary check by executing BNDCHK instruction with comparison specifiers
US6738977B1 (en) * 2000-05-31 2004-05-18 International Business Machines Corporation Class sharing between multiple virtual machines
GB0024496D0 (en) * 2000-10-05 2000-11-22 Pettigrew Michael New compact disc case
US6701417B2 (en) * 2001-04-11 2004-03-02 Sun Microsystems, Inc. Method and apparatus for supporting multiple cache line invalidations per cycle
US6684297B2 (en) * 2001-04-11 2004-01-27 Sun Microsystems, Inc. Reverse directory for facilitating accesses involving a lower-level cache
US6862693B2 (en) * 2001-04-13 2005-03-01 Sun Microsystems, Inc. Providing fault-tolerance by comparing addresses and data from redundant processors running in lock-step
US6910209B2 (en) * 2001-04-30 2005-06-21 Sun Microsystems, Inc. Clean thread termination
WO2004001527A2 (en) * 2001-06-26 2003-12-31 Sun Microsystems, Inc. Method and apparatus for facilitating speculative loads in a multiprocessor system
US6901491B2 (en) * 2001-10-22 2005-05-31 Sun Microsystems, Inc. Method and apparatus for integration of communication links with a remote direct memory access protocol
US6892202B2 (en) * 2002-04-17 2005-05-10 Sun Microsystems, Inc. Optimistic transaction compiler
US7131120B2 (en) * 2002-05-16 2006-10-31 Sun Microsystems, Inc. Inter Java virtual machine (JVM) resource locking mechanism
US7634806B2 (en) * 2002-05-30 2009-12-15 Microsoft Corporation Peer assembly inspection
US7424716B1 (en) * 2002-07-18 2008-09-09 Cisco Technology, Inc. Method for tracking an event through multiple module-specific files
US8073935B2 (en) * 2002-07-25 2011-12-06 Oracle America, Inc. Pluggable semantic verification and validation of configuration data
EP1418501A1 (en) * 2002-11-08 2004-05-12 Dunes Technologies S.A. Method of administration of applications on virtual machines
US6938130B2 (en) * 2003-02-13 2005-08-30 Sun Microsystems Inc. Method and apparatus for delaying interfering accesses from other threads during transactional program execution
US6862664B2 (en) * 2003-02-13 2005-03-01 Sun Microsystems, Inc. Method and apparatus for avoiding locks by speculatively executing critical sections
JP4345334B2 (en) * 2003-03-28 2009-10-14 日本電気株式会社 Fault tolerant computer system, program parallel execution method and program
US7222221B1 (en) * 2004-02-06 2007-05-22 Vmware, Inc. Maintaining coherency of derived data in a computer system
US7376078B1 (en) * 2004-03-24 2008-05-20 Juniper Networks, Inc. Selective replay of a state information within a computing device

Patent Citations (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5999946A (en) * 1996-04-10 1999-12-07 Harris Corporation Databases in telecommunications
US6009271A (en) * 1996-10-28 1999-12-28 Bmc Software, Inc. Method of retrieving data from a relational database
US5920725A (en) * 1997-07-02 1999-07-06 Adaptivity Inc. Run-time object-synthesis and transparent client/server updating of distributed objects using a meta server of all object descriptors
US5987254A (en) * 1997-07-14 1999-11-16 Hewlett Packard Company System-wide memoization of array dependence information
US6016512A (en) * 1997-11-20 2000-01-18 Telcordia Technologies, Inc. Enhanced domain name service using a most frequently used domain names table and a validity code table
US20030204517A1 (en) * 1998-05-29 2003-10-30 Brian Skinner Method and apparatus of performing active update notification
US6347312B1 (en) * 1998-11-05 2002-02-12 International Business Machines Corporation Lightweight directory access protocol (LDAP) directory server cache mechanism and method
US6725333B1 (en) * 1999-04-22 2004-04-20 International Business Machines Corporation System and method for managing cachable entities
US6636853B1 (en) * 1999-08-30 2003-10-21 Morphism, Llc Method and apparatus for representing and navigating search results
US6834290B1 (en) * 1999-11-15 2004-12-21 Quest Software, Inc. System and method for developing a cost-effective reorganization plan for data reorganization
US7065538B2 (en) * 2000-02-11 2006-06-20 Quest Software, Inc. System and method for reconciling transactions between a replication system and a recovered database
US6457020B1 (en) * 2000-03-20 2002-09-24 International Business Machines Corporation Query optimization using a multi-layered object cache
US6654766B1 (en) * 2000-04-04 2003-11-25 International Business Machines Corporation System and method for caching sets of objects
US20020087798A1 (en) * 2000-11-15 2002-07-04 Vijayakumar Perincherry System and method for adaptive data caching
US6871780B2 (en) * 2000-11-27 2005-03-29 Airclic, Inc. Scalable distributed database system and method for linking codes to internet information
US20020107835A1 (en) * 2001-02-08 2002-08-08 Coram Michael T. System and method for adaptive result set caching
US7162467B2 (en) * 2001-02-22 2007-01-09 Greenplum, Inc. Systems and methods for managing distributed database resources
US20040205092A1 (en) * 2003-03-27 2004-10-14 Alan Longo Data storage and caching architecture
US20040193656A1 (en) * 2003-03-28 2004-09-30 Pizzo Michael J. Systems and methods for caching and invalidating database results and derived objects
US20060026154A1 (en) * 2004-07-30 2006-02-02 Mehmet Altinel System and method for adaptive database caching

Cited By (217)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080098173A1 (en) * 2006-10-20 2008-04-24 Lakshminarayanan Chidambaran Consistent client-side cache
US10296629B2 (en) 2006-10-20 2019-05-21 Oracle International Corporation Server supporting a consistent client-side cache
US20080098041A1 (en) * 2006-10-20 2008-04-24 Lakshminarayanan Chidambaran Server supporting a consistent client-side cache
US9697253B2 (en) * 2006-10-20 2017-07-04 Oracle International Corporation Consistent client-side cache
EP2118823B1 (en) * 2007-03-01 2020-04-15 Zipcar, Inc. Multi-tiered fleet management cache
WO2009064623A1 (en) * 2007-11-13 2009-05-22 Vmware, Inc. A network device and method for monitoring of backend transactions in data centers
US20090125496A1 (en) * 2007-11-13 2009-05-14 B-Hive Networks, Inc Network device and method for monitoring of backend transactions in data centers
US9519526B2 (en) 2007-12-05 2016-12-13 Box, Inc. File management system and collaboration service and integration capabilities with third party applications
US8583619B2 (en) 2007-12-05 2013-11-12 Box, Inc. Methods and systems for open source collaboration in an application service provider environment
US8326814B2 (en) 2007-12-05 2012-12-04 Box, Inc. Web-based file management system and service
US20090210459A1 (en) * 2008-02-19 2009-08-20 International Business Machines Corporation Document synchronization solution
US9251236B2 (en) 2008-02-19 2016-02-02 International Business Machines Corporation Document synchronization solution
US8650154B2 (en) 2008-02-19 2014-02-11 International Business Machines Corporation Document synchronization solution
US20090254589A1 (en) * 2008-04-07 2009-10-08 International Business Machines Corporation Client side caching of synchronized data
US8725679B2 (en) * 2008-04-07 2014-05-13 International Business Machines Corporation Client side caching of synchronized data
US8516003B2 (en) 2008-05-30 2013-08-20 Armanta, Inc. System for manipulating data using a user entity cache
US9087067B2 (en) 2008-05-30 2015-07-21 Armanta, Inc. System, method, and computer program product for modeling changes to large scale datasets
US20090300032A1 (en) * 2008-05-30 2009-12-03 Chirlian Peter J System, Method, and Computer Program Product for Modeling Changes to Large Scale Datasets
US8239416B2 (en) * 2008-05-30 2012-08-07 Armanta, Inc. System, method, and computer program product for modeling changes to large scale datasets
US20100161643A1 (en) * 2008-12-24 2010-06-24 Yahoo! Inc. Segmentation of interleaved query missions into query chains
US20110173947A1 (en) * 2010-01-19 2011-07-21 General Electric Company System and method for gas turbine power augmentation
US20150032703A1 (en) * 2010-05-12 2015-01-29 Microsoft Corporation Getting dependency metadata using statement execution plans
US10554426B2 (en) 2011-01-20 2020-02-04 Box, Inc. Real time notification of activities that occur in a web-based collaboration environment
US9015601B2 (en) 2011-06-21 2015-04-21 Box, Inc. Batch uploading of content to a web-based collaboration environment
US9063912B2 (en) 2011-06-22 2015-06-23 Box, Inc. Multimedia content preview rendering in a cloud content management system
US9978040B2 (en) 2011-07-08 2018-05-22 Box, Inc. Collaboration sessions in a workspace on a cloud-based content management system
US9652741B2 (en) 2011-07-08 2017-05-16 Box, Inc. Desktop application for access and interaction with workspaces in a cloud-based content management system and synchronization mechanisms thereof
US20130060795A1 (en) * 2011-09-07 2013-03-07 Unisys Corp. Prepared statements to improve performance in database interfaces
US9197718B2 (en) 2011-09-23 2015-11-24 Box, Inc. Central management and control of user-contributed content in a web-based collaboration environment and management console thereof
US8515902B2 (en) 2011-10-14 2013-08-20 Box, Inc. Automatic and semi-automatic tagging features of work items in a shared workspace for metadata tracking in a cloud-based content management system with selective or optional user contribution
US8990151B2 (en) 2011-10-14 2015-03-24 Box, Inc. Automatic and semi-automatic tagging features of work items in a shared workspace for metadata tracking in a cloud-based content management system with selective or optional user contribution
US11210610B2 (en) 2011-10-26 2021-12-28 Box, Inc. Enhanced multimedia content preview rendering in a cloud content management system
US9098474B2 (en) 2011-10-26 2015-08-04 Box, Inc. Preview pre-generation based on heuristics and algorithmic prediction/assessment of predicted user behavior for enhancement of user experience
US20130124458A1 (en) * 2011-11-16 2013-05-16 Tomas Barreto Resource effective incremental updating of a remote client with events which occurred via a cloud-enabled platform
US9015248B2 (en) * 2011-11-16 2015-04-21 Box, Inc. Managing updates at clients used by a user to access a cloud-based collaboration service
US8990307B2 (en) * 2011-11-16 2015-03-24 Box, Inc. Resource effective incremental updating of a remote client with events which occurred via a cloud-enabled platform
US11537630B2 (en) 2011-11-29 2022-12-27 Box, Inc. Mobile platform file and folder selection functionalities for offline access and synchronization
US11853320B2 (en) 2011-11-29 2023-12-26 Box, Inc. Mobile platform file and folder selection functionalities for offline access and synchronization
US9773051B2 (en) 2011-11-29 2017-09-26 Box, Inc. Mobile platform file and folder selection functionalities for offline access and synchronization
US10909141B2 (en) 2011-11-29 2021-02-02 Box, Inc. Mobile platform file and folder selection functionalities for offline access and synchronization
US9019123B2 (en) 2011-12-22 2015-04-28 Box, Inc. Health check services for web-based collaboration environments
US9904435B2 (en) 2012-01-06 2018-02-27 Box, Inc. System and method for actionable event generation for task delegation and management via a discussion forum in a web-based collaboration environment
US11232481B2 (en) 2012-01-30 2022-01-25 Box, Inc. Extended applications of multimedia content previews in the cloud-based content management system
US10713624B2 (en) 2012-02-24 2020-07-14 Box, Inc. System and method for promoting enterprise adoption of a web-based collaboration environment
US9965745B2 (en) 2012-02-24 2018-05-08 Box, Inc. System and method for promoting enterprise adoption of a web-based collaboration environment
US9195636B2 (en) 2012-03-07 2015-11-24 Box, Inc. Universal file type preview for mobile devices
US9054919B2 (en) 2012-04-05 2015-06-09 Box, Inc. Device pinning capability for enterprise cloud service and storage accounts
US9575981B2 (en) 2012-04-11 2017-02-21 Box, Inc. Cloud service enabled to handle a set of files depicted to a user as a single file in a native operating system
US9413587B2 (en) 2012-05-02 2016-08-09 Box, Inc. System and method for a third-party application to access content within a cloud-based platform
US9691051B2 (en) 2012-05-21 2017-06-27 Box, Inc. Security enhancement through application access control
US8914900B2 (en) 2012-05-23 2014-12-16 Box, Inc. Methods, architectures and security mechanisms for a third-party application to access content in a cloud-based platform
US9280613B2 (en) 2012-05-23 2016-03-08 Box, Inc. Metadata enabled third-party application access of content at a cloud-based platform via a native client to the cloud-based platform
US9027108B2 (en) 2012-05-23 2015-05-05 Box, Inc. Systems and methods for secure file portability between mobile applications on a mobile device
US9552444B2 (en) 2012-05-23 2017-01-24 Box, Inc. Identification verification mechanisms for a third-party application to access content in a cloud-based platform
US9021099B2 (en) 2012-07-03 2015-04-28 Box, Inc. Load balancing secure FTP connections among multiple FTP servers
US8719445B2 (en) 2012-07-03 2014-05-06 Box, Inc. System and method for load balancing multiple file transfer protocol (FTP) servers to service FTP connections for a cloud-based service
US9792320B2 (en) 2012-07-06 2017-10-17 Box, Inc. System and method for performing shard migration to support functions of a cloud-based service
US10452667B2 (en) 2012-07-06 2019-10-22 Box Inc. Identification of people as search results from key-word based searches of content in a cloud-based environment
US9712510B2 (en) 2012-07-06 2017-07-18 Box, Inc. Systems and methods for securely submitting comments among users via external messaging applications in a cloud-based platform
US9473532B2 (en) 2012-07-19 2016-10-18 Box, Inc. Data loss prevention (DLP) methods by a cloud service including third party integration architectures
US9237170B2 (en) 2012-07-19 2016-01-12 Box, Inc. Data loss prevention (DLP) methods and architectures by a cloud service
US9794256B2 (en) 2012-07-30 2017-10-17 Box, Inc. System and method for advanced control tools for administrators in a cloud-based service
US8868574B2 (en) 2012-07-30 2014-10-21 Box, Inc. System and method for advanced search and filtering mechanisms for enterprise administrators in a cloud-based environment
US8745267B2 (en) 2012-08-19 2014-06-03 Box, Inc. Enhancement of upload and/or download performance based on client and/or server feedback information
US9369520B2 (en) 2012-08-19 2016-06-14 Box, Inc. Enhancement of upload and/or download performance based on client and/or server feedback information
US9729675B2 (en) 2012-08-19 2017-08-08 Box, Inc. Enhancement of upload and/or download performance based on client and/or server feedback information
US9558202B2 (en) 2012-08-27 2017-01-31 Box, Inc. Server side techniques for reducing database workload in implementing selective subfolder synchronization in a cloud-based environment
US9135462B2 (en) 2012-08-29 2015-09-15 Box, Inc. Upload and download streaming encryption to/from a cloud-based platform
US9450926B2 (en) 2012-08-29 2016-09-20 Box, Inc. Upload and download streaming encryption to/from a cloud-based platform
US9311071B2 (en) 2012-09-06 2016-04-12 Box, Inc. Force upgrade of a mobile application via a server side configuration file
US9117087B2 (en) 2012-09-06 2015-08-25 Box, Inc. System and method for creating a secure channel for inter-application communication based on intents
US9195519B2 (en) 2012-09-06 2015-11-24 Box, Inc. Disabling the self-referential appearance of a mobile application in an intent via a background registration
US9292833B2 (en) 2012-09-14 2016-03-22 Box, Inc. Batching notifications of activities that occur in a web-based collaboration environment
US10200256B2 (en) 2012-09-17 2019-02-05 Box, Inc. System and method of a manipulative handle in an interactive mobile user interface
US9553758B2 (en) 2012-09-18 2017-01-24 Box, Inc. Sandboxing individual applications to specific user folders in a cloud-based service
US10915492B2 (en) 2012-09-19 2021-02-09 Box, Inc. Cloud-based platform enabled with media content indexed for text-based searches and/or metadata extraction
US9959420B2 (en) 2012-10-02 2018-05-01 Box, Inc. System and method for enhanced security and management mechanisms for enterprise administrators in a cloud-based environment
US9495364B2 (en) 2012-10-04 2016-11-15 Box, Inc. Enhanced quick search features, low-barrier commenting/interactive features in a collaboration platform
US9705967B2 (en) 2012-10-04 2017-07-11 Box, Inc. Corporate user discovery and identification of recommended collaborators in a cloud platform
US9665349B2 (en) 2012-10-05 2017-05-30 Box, Inc. System and method for generating embeddable widgets which enable access to a cloud-based collaboration platform
US9628268B2 (en) 2012-10-17 2017-04-18 Box, Inc. Remote key management in a cloud-based environment
US10235383B2 (en) 2012-12-19 2019-03-19 Box, Inc. Method and apparatus for synchronization of items with read-only permissions in a cloud-based environment
US9396245B2 (en) 2013-01-02 2016-07-19 Box, Inc. Race condition handling in a system which incrementally updates clients with events that occurred in a cloud-based collaboration platform
US9953036B2 (en) 2013-01-09 2018-04-24 Box, Inc. File system monitoring in a system which incrementally updates clients with events that occurred in a cloud-based collaboration platform
US9507795B2 (en) 2013-01-11 2016-11-29 Box, Inc. Functionalities, features, and user interface of a synchronization client to a cloud-based environment
US10599671B2 (en) 2013-01-17 2020-03-24 Box, Inc. Conflict resolution, retry condition management, and handling of problem files for the synchronization client to a cloud-based platform
US10725968B2 (en) 2013-05-10 2020-07-28 Box, Inc. Top down delete or unsynchronization on delete of and depiction of item synchronization with a synchronization client to a cloud-based platform
US10846074B2 (en) 2013-05-10 2020-11-24 Box, Inc. Identification and handling of items to be ignored for synchronization with a cloud-based platform by a synchronization client
US9633037B2 (en) 2013-06-13 2017-04-25 Box, Inc Systems and methods for synchronization event building and/or collapsing by a synchronization component of a cloud-based platform
US10877937B2 (en) 2013-06-13 2020-12-29 Box, Inc. Systems and methods for synchronization event building and/or collapsing by a synchronization component of a cloud-based platform
US9805050B2 (en) 2013-06-21 2017-10-31 Box, Inc. Maintaining and updating file system shadows on a local device by a synchronization client of a cloud-based platform
US11531648B2 (en) 2013-06-21 2022-12-20 Box, Inc. Maintaining and updating file system shadows on a local device by a synchronization client of a cloud-based platform
US10110656B2 (en) 2013-06-25 2018-10-23 Box, Inc. Systems and methods for providing shell communication in a cloud-based platform
US10229134B2 (en) 2013-06-25 2019-03-12 Box, Inc. Systems and methods for managing upgrades, migration of user data and improving performance of a cloud-based platform
US9535924B2 (en) 2013-07-30 2017-01-03 Box, Inc. Scalability improvement in a system which incrementally updates clients with events that occurred in a cloud-based collaboration platform
US10044773B2 (en) 2013-09-13 2018-08-07 Box, Inc. System and method of a multi-functional managing user interface for accessing a cloud-based platform via mobile devices
US9535909B2 (en) 2013-09-13 2017-01-03 Box, Inc. Configurable event-based automation architecture for cloud-based collaboration platforms
US10509527B2 (en) 2013-09-13 2019-12-17 Box, Inc. Systems and methods for configuring event-based automation in cloud-based collaboration platforms
US9519886B2 (en) 2013-09-13 2016-12-13 Box, Inc. Simultaneous editing/accessing of content by collaborator invitation through a web-based or mobile application to a cloud-based collaboration platform
US9704137B2 (en) 2013-09-13 2017-07-11 Box, Inc. Simultaneous editing/accessing of content by collaborator invitation through a web-based or mobile application to a cloud-based collaboration platform
US8892679B1 (en) 2013-09-13 2014-11-18 Box, Inc. Mobile device, methods and user interfaces thereof in a mobile device platform featuring multifunctional access and engagement in a collaborative environment provided by a cloud-based platform
US11435865B2 (en) 2013-09-13 2022-09-06 Box, Inc. System and methods for configuring event-based automation in cloud-based collaboration platforms
US11822759B2 (en) 2013-09-13 2023-11-21 Box, Inc. System and methods for configuring event-based automation in cloud-based collaboration platforms
US9483473B2 (en) 2013-09-13 2016-11-01 Box, Inc. High availability architecture for a cloud-based concurrent-access collaboration platform
US9213684B2 (en) 2013-09-13 2015-12-15 Box, Inc. System and method for rendering document in web browser or mobile device regardless of third-party plug-in software
US10866931B2 (en) 2013-10-22 2020-12-15 Box, Inc. Desktop application for accessing a cloud collaboration platform
US10530854B2 (en) 2014-05-30 2020-01-07 Box, Inc. Synchronization of permissioned content in cloud-based environments
US9602514B2 (en) 2014-06-16 2017-03-21 Box, Inc. Enterprise mobility management and verification of a managed application by a content provider
US10574442B2 (en) 2014-08-29 2020-02-25 Box, Inc. Enhanced remote key management for an enterprise in a cloud-based environment
US10708323B2 (en) 2014-08-29 2020-07-07 Box, Inc. Managing flow-based interactions with cloud-based shared content
US10708321B2 (en) 2014-08-29 2020-07-07 Box, Inc. Configurable metadata-based automation and content classification architecture for cloud-based collaboration platforms
US10038731B2 (en) 2014-08-29 2018-07-31 Box, Inc. Managing flow-based interactions with cloud-based shared content
US11876845B2 (en) 2014-08-29 2024-01-16 Box, Inc. Configurable metadata-based automation and content classification architecture for cloud-based collaboration platforms
US9894119B2 (en) 2014-08-29 2018-02-13 Box, Inc. Configurable metadata-based automation and content classification architecture for cloud-based collaboration platforms
US9756022B2 (en) 2014-08-29 2017-09-05 Box, Inc. Enhanced remote key management for an enterprise in a cloud-based environment
US11146600B2 (en) 2014-08-29 2021-10-12 Box, Inc. Configurable metadata-based automation and content classification architecture for cloud-based collaboration platforms
US10860604B1 (en) * 2014-12-10 2020-12-08 Amazon Technologies, Inc. Scalable tracking for database udpates according to a secondary index
US10885036B2 (en) * 2015-02-03 2021-01-05 Red Hat, Inc. Obtaining incremental updates from a database using a partial query
US10212257B2 (en) 2015-05-14 2019-02-19 Deephaven Data Labs Llc Persistent query dispatch and execution architecture
US10019138B2 (en) 2015-05-14 2018-07-10 Illumon Llc Applying a GUI display effect formula in a hidden column to a section of data
US9836494B2 (en) 2015-05-14 2017-12-05 Illumon Llc Importation, presentation, and persistent storage of data
US10242040B2 (en) 2015-05-14 2019-03-26 Deephaven Data Labs Llc Parsing and compiling data system queries
US10241960B2 (en) 2015-05-14 2019-03-26 Deephaven Data Labs Llc Historical data replay utilizing a computer system
US10242041B2 (en) 2015-05-14 2019-03-26 Deephaven Data Labs Llc Dynamic filter processing
US9886469B2 (en) 2015-05-14 2018-02-06 Walleye Software, LLC System performance logging of complex remote query processor query operations
US9612959B2 (en) 2015-05-14 2017-04-04 Walleye Software, LLC Distributed and optimized garbage collection of remote and exported table handle links to update propagation graph nodes
US10346394B2 (en) 2015-05-14 2019-07-09 Deephaven Data Labs Llc Importation, presentation, and persistent storage of data
US10353893B2 (en) 2015-05-14 2019-07-16 Deephaven Data Labs Llc Data partitioning and ordering
US9613018B2 (en) 2015-05-14 2017-04-04 Walleye Software, LLC Applying a GUI display effect formula in a hidden column to a section of data
US10452649B2 (en) 2015-05-14 2019-10-22 Deephaven Data Labs Llc Computer data distribution architecture
US10496639B2 (en) 2015-05-14 2019-12-03 Deephaven Data Labs Llc Computer data distribution architecture
US9760591B2 (en) 2015-05-14 2017-09-12 Walleye Software, LLC Dynamic code loading
US10198466B2 (en) 2015-05-14 2019-02-05 Deephaven Data Labs Llc Data store access permission system with interleaved application of deferred access control filters
US10540351B2 (en) 2015-05-14 2020-01-21 Deephaven Data Labs Llc Query dispatch and execution architecture
US9613109B2 (en) 2015-05-14 2017-04-04 Walleye Software, LLC Query task processing based on memory allocation and performance criteria
US10552412B2 (en) 2015-05-14 2020-02-04 Deephaven Data Labs Llc Query task processing based on memory allocation and performance criteria
US10565206B2 (en) 2015-05-14 2020-02-18 Deephaven Data Labs Llc Query task processing based on memory allocation and performance criteria
US10565194B2 (en) 2015-05-14 2020-02-18 Deephaven Data Labs Llc Computer system for join processing
US9710511B2 (en) 2015-05-14 2017-07-18 Walleye Software, LLC Dynamic table index mapping
US10572474B2 (en) 2015-05-14 2020-02-25 Deephaven Data Labs Llc Computer data system data source refreshing using an update propagation graph
US10198465B2 (en) 2015-05-14 2019-02-05 Deephaven Data Labs Llc Computer data system current row position query language construct and array processing query language constructs
US10621168B2 (en) 2015-05-14 2020-04-14 Deephaven Data Labs Llc Dynamic join processing using real time merged notification listener
US10176211B2 (en) 2015-05-14 2019-01-08 Deephaven Data Labs Llc Dynamic table index mapping
US10642829B2 (en) 2015-05-14 2020-05-05 Deephaven Data Labs Llc Distributed and optimized garbage collection of exported data objects
US9805084B2 (en) 2015-05-14 2017-10-31 Walleye Software, LLC Computer data system data source refreshing using an update propagation graph
US9836495B2 (en) 2015-05-14 2017-12-05 Illumon Llc Computer assisted completion of hyperlink command segments
US10678787B2 (en) 2015-05-14 2020-06-09 Deephaven Data Labs Llc Computer assisted completion of hyperlink command segments
US10691686B2 (en) 2015-05-14 2020-06-23 Deephaven Data Labs Llc Computer data system position-index mapping
US11514037B2 (en) 2015-05-14 2022-11-29 Deephaven Data Labs Llc Remote data object publishing/subscribing system having a multicast key-value protocol
US10069943B2 (en) 2015-05-14 2018-09-04 Illumon Llc Query dispatch and execution architecture
US11687529B2 (en) 2015-05-14 2023-06-27 Deephaven Data Labs Llc Single input graphical user interface control element and method
US9898496B2 (en) 2015-05-14 2018-02-20 Illumon Llc Dynamic code loading
US11263211B2 (en) 2015-05-14 2022-03-01 Deephaven Data Labs, LLC Data partitioning and ordering
US11663208B2 (en) 2015-05-14 2023-05-30 Deephaven Data Labs Llc Computer data system current row position query language construct and array processing query language constructs
US10002155B1 (en) 2015-05-14 2018-06-19 Illumon Llc Dynamic code loading
US11249994B2 (en) 2015-05-14 2022-02-15 Deephaven Data Labs Llc Query task processing based on memory allocation and performance criteria
US11238036B2 (en) 2015-05-14 2022-02-01 Deephaven Data Labs, LLC System performance logging of complex remote query processor query operations
US10002153B2 (en) 2015-05-14 2018-06-19 Illumon Llc Remote data object publishing/subscribing system having a multicast key-value protocol
US10003673B2 (en) 2015-05-14 2018-06-19 Illumon Llc Computer data distribution architecture
US9639570B2 (en) 2015-05-14 2017-05-02 Walleye Software, LLC Data store access permission system with interleaved application of deferred access control filters
US11556528B2 (en) 2015-05-14 2023-01-17 Deephaven Data Labs Llc Dynamic updating of query result displays
US9672238B2 (en) 2015-05-14 2017-06-06 Walleye Software, LLC Dynamic filter processing
US10915526B2 (en) 2015-05-14 2021-02-09 Deephaven Data Labs Llc Historical data replay utilizing a computer system
US9679006B2 (en) 2015-05-14 2017-06-13 Walleye Software, LLC Dynamic join processing using real time merged notification listener
US10922311B2 (en) 2015-05-14 2021-02-16 Deephaven Data Labs Llc Dynamic updating of query result displays
US10929394B2 (en) 2015-05-14 2021-02-23 Deephaven Data Labs Llc Persistent query dispatch and execution architecture
US9619210B2 (en) 2015-05-14 2017-04-11 Walleye Software, LLC Parsing and compiling data system queries
US11023462B2 (en) 2015-05-14 2021-06-01 Deephaven Data Labs, LLC Single input graphical user interface control element and method
US9934266B2 (en) 2015-05-14 2018-04-03 Walleye Software, LLC Memory-efficient computer system for dynamic updating of join processing
US9690821B2 (en) 2015-05-14 2017-06-27 Walleye Software, LLC Computer data system position-index mapping
US11151133B2 (en) 2015-05-14 2021-10-19 Deephaven Data Labs, LLC Computer data distribution architecture
WO2016183548A1 (en) * 2015-05-14 2016-11-17 Walleye Software, LLC Dynamic filter processing
US11275767B2 (en) 2015-07-15 2022-03-15 International Business Machines Corporation Analyzing application behavior to determine relationships between data
US10706075B2 (en) * 2015-07-15 2020-07-07 International Business Machines Corporation Analyzing application behavior to determine relationships between data
US11550557B2 (en) 2016-02-12 2023-01-10 Nutanix, Inc. Virtualized file server
US11579861B2 (en) 2016-02-12 2023-02-14 Nutanix, Inc. Virtualized file server smart data ingestion
US11645065B2 (en) 2016-02-12 2023-05-09 Nutanix, Inc. Virtualized file server user views
US11669320B2 (en) 2016-02-12 2023-06-06 Nutanix, Inc. Self-healing virtualized file server
US11550558B2 (en) 2016-02-12 2023-01-10 Nutanix, Inc. Virtualized file server deployment
US11550559B2 (en) 2016-02-12 2023-01-10 Nutanix, Inc. Virtualized file server rolling upgrade
US11537384B2 (en) 2016-02-12 2022-12-27 Nutanix, Inc. Virtualized file server distribution across clusters
US11544049B2 (en) 2016-02-12 2023-01-03 Nutanix, Inc. Virtualized file server disaster recovery
US11922157B2 (en) 2016-02-12 2024-03-05 Nutanix, Inc. Virtualized file server
US11888599B2 (en) 2016-05-20 2024-01-30 Nutanix, Inc. Scalable leadership election in a multi-processing computing environment
US10936559B1 (en) 2016-09-28 2021-03-02 Amazon Technologies, Inc. Strongly-consistent secondary index for a distributed data set
US11562034B2 (en) 2016-12-02 2023-01-24 Nutanix, Inc. Transparent referrals for distributed file servers
US11568073B2 (en) 2016-12-02 2023-01-31 Nutanix, Inc. Handling permissions for virtualized file servers
US11775397B2 (en) 2016-12-05 2023-10-03 Nutanix, Inc. Disaster recovery for distributed file servers, including metadata fixers
US11281484B2 (en) 2016-12-06 2022-03-22 Nutanix, Inc. Virtualized server systems and methods including scaling of file system virtual machines
US11922203B2 (en) 2016-12-06 2024-03-05 Nutanix, Inc. Virtualized server systems and methods including scaling of file system virtual machines
CN108241647A (en) * 2016-12-23 2018-07-03 北京奇虎科技有限公司 Data processing and the method and apparatus of inquiry
US11734276B2 (en) * 2016-12-29 2023-08-22 Beijing Qiyi Century Science & Technology Co., Ltd. Method and apparatus for updating search cache to improve the update speed of hot content
US11940990B1 (en) 2017-06-16 2024-03-26 Amazon Technologies, Inc. Global clock values for consistent queries to replicated data
US11314717B1 (en) 2017-06-23 2022-04-26 Amazon Technologies, Inc. Scalable architecture for propagating updates to replicated data
US11574018B2 (en) 2017-08-24 2023-02-07 Deephaven Data Labs Llc Computer data distribution architecture connecting an update propagation graph through multiple remote query processing
US11860948B2 (en) 2017-08-24 2024-01-02 Deephaven Data Labs Llc Keyed row selection
US11941060B2 (en) 2017-08-24 2024-03-26 Deephaven Data Labs Llc Computer data distribution architecture for efficient distribution and synchronization of plotting processing and data
US10002154B1 (en) 2017-08-24 2018-06-19 Illumon Llc Computer data system data source having an update propagation graph with feedback cyclicality
US10783191B1 (en) 2017-08-24 2020-09-22 Deephaven Data Labs Llc Computer data distribution architecture for efficient distribution and synchronization of plotting processing and data
US10866943B1 (en) 2017-08-24 2020-12-15 Deephaven Data Labs Llc Keyed row selection
US11126662B2 (en) 2017-08-24 2021-09-21 Deephaven Data Labs Llc Computer data distribution architecture connecting an update propagation graph through multiple remote query processors
US11449557B2 (en) 2017-08-24 2022-09-20 Deephaven Data Labs Llc Computer data distribution architecture for efficient distribution and synchronization of plotting processing and data
US10909183B2 (en) 2017-08-24 2021-02-02 Deephaven Data Labs Llc Computer data system data source refreshing using an update propagation graph having a merged join listener
US10241965B1 (en) 2017-08-24 2019-03-26 Deephaven Data Labs Llc Computer data distribution architecture connecting an update propagation graph through multiple remote query processors
US10198469B1 (en) 2017-08-24 2019-02-05 Deephaven Data Labs Llc Computer data system data source refreshing using an update propagation graph having a merged join listener
US10657184B2 (en) 2017-08-24 2020-05-19 Deephaven Data Labs Llc Computer data system data source having an update propagation graph with feedback cyclicality
CN108363741A (en) * 2018-01-22 2018-08-03 中国平安人寿保险股份有限公司 Big data unified interface method, apparatus, equipment and storage medium
US11567934B2 (en) 2018-04-20 2023-01-31 Oracle International Corporation Consistent client-side caching for fine grained invalidations
US11770447B2 (en) 2018-10-31 2023-09-26 Nutanix, Inc. Managing high-availability file servers
CN109710859A (en) * 2019-01-21 2019-05-03 北京字节跳动网络技术有限公司 Data query method and apparatus
CN111177161A (en) * 2019-11-07 2020-05-19 腾讯科技(深圳)有限公司 Data processing method and device, computing equipment and storage medium
US11625373B2 (en) 2020-04-30 2023-04-11 International Business Machines Corporation Determining additions, deletions and updates to database tables
US11768809B2 (en) 2020-05-08 2023-09-26 Nutanix, Inc. Managing incremental snapshots for fast leader node bring-up
US11860892B2 (en) 2020-09-29 2024-01-02 Amazon Technologies, Inc. Offline index builds for database tables
US11880385B1 (en) 2020-09-29 2024-01-23 Amazon Technologies, Inc. Ordering updates to secondary indexes using conditional operations
US11947952B2 (en) 2022-07-15 2024-04-02 Nutanix, Inc. Virtualized file server disaster recovery
CN115858408A (en) * 2022-12-29 2023-03-28 南京维拓科技股份有限公司 Method for transmitting design parameters in industrial design process

Also Published As

Publication number Publication date
US20060271542A1 (en) 2006-11-30
WO2006128112A2 (en) 2006-11-30
US20060271575A1 (en) 2006-11-30
WO2006128062A2 (en) 2006-11-30
US20060271511A1 (en) 2006-11-30
US20060271931A1 (en) 2006-11-30
US20070011667A1 (en) 2007-01-11
US20060271395A1 (en) 2006-11-30
US20060271930A1 (en) 2006-11-30
US20070088762A1 (en) 2007-04-19
US7716377B2 (en) 2010-05-11
WO2006128112A3 (en) 2009-04-30
US20060271557A1 (en) 2006-11-30
WO2006128062A3 (en) 2009-04-16

Similar Documents

Publication Publication Date Title
US20060271510A1 (en) Database Caching and Invalidation using Database Provided Facilities for Query Dependency Analysis
US11151079B2 (en) Merging database operations for serializable transaction execution
US7376682B2 (en) Time model
EP2947582A1 (en) Computing device and method for executing database operation command
US8793288B2 (en) Online access to database snapshots
US11334474B2 (en) Fast change impact analysis tool for large-scale software systems
US11487742B2 (en) Consistency checks between database systems
Antognini Troubleshooting Oracle Performance
US11580228B2 (en) Coverage of web application analysis
US11748349B2 (en) Customizable filtering for query plan stability in database systems using abstract query plans
US11204746B2 (en) Encoding dependencies in call graphs
Glasbergen et al. Sentinel: universal analysis and insight for data systems
EP3841476A1 (en) Scalable pre-analysis of dynamic applications
Butrovich et al. Tastes great! less filling! high performance and accurate training data collection for self-driving database management systems
US10909019B2 (en) Runtime performance introspection
US10768913B2 (en) Method for performing deep static analysis with or without source code
CN113886205A (en) Database performance bottleneck positioning analysis method, device and system and storage medium
US20230376405A1 (en) Enabling of development checks
US11797419B2 (en) Task-specific logging in digital computer systems
US11789948B2 (en) Computational dependency directory
EP3915029B1 (en) Scalable incremental analysis using caller and callee summaries
US10552408B2 (en) Automatic linearizability checking of operations on concurrent data structures
US20210240596A1 (en) Source code file retrieval
CN116108055A (en) Database dangerous statement detection method, system, equipment and storage medium
Glasbergen Universal Database System Analysis for Insight and Adaptivity

Legal Events

Date Code Title Description
AS Assignment

Owner name: TERRACOTTA, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:HARWARD, NATHANIEL D;GEWEKE, ANDREW R;VOSKOBOYNIK, ALEXANDER;REEL/FRAME:021509/0523;SIGNING DATES FROM 20060529 TO 20060531

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION