Application of database or data structure (e.g., distributed, multimedia, image)

System and method for caching data for a mobile application

6941310

Abstract

A cache table comprises a set of access parameters and a set of data columns. One or more instances of a cache table are stored on a mobile computing device. Each instance includes an argument (a unique set of values for the access parameters) and a result set (a set of values for the data columns). Thus, each result in a result set comprises the argument and corresponding column values. Cached result sets have specified periods of validity, and may or may not be usable after becoming invalid. Valid cached data may be used regardless of whether a connection is available to a data source (e.g., data or application server). Invalid data may be used for a period of time if no connection is available to the data source. Data in a cache table may be selectively updated from a data source without synchronizing the entire local database.


Claims

1. A system for caching data on a mobile computing device connectable to a central data source through a wireless link, comprising:

a database configured to selectively operate in either of an on-line mode and an off-line mode with respect to a central data source;

within the database, a cache table defined by:

a set of access parameters corresponding to a first set of attributes of the data source; and

a second set of attributes of the central data source; within the database, one or more instances of said cache table, wherein each said cache table instance comprises:

an argument comprising a value for each of said access parameters; and

a set of results, wherein each said result comprises a value for each of said second set of attributes of the data source; and

for each said cache table instance, information for determining whether said result set is usable;

wherein the database facilitates caching of data from a data source, on a mobile computing device coupled to the data source with a discontinuously available communication link.

2. The system of claim 1 , wherein said information for a first result set of a first cache table instance comprises one or more of:

a response-date parameter configured to indicate when said first result set was last provided to the database from the data source;

a last-modified-date parameter configured to indicate when said first result set was last modified at the data source;

a time-to-live parameter configured to indicate a first period of time during which said first result set is valid, wherein said first result set is usable if said first result set is valid; and

a staleness parameter configured to indicate a second period of time, starting at the expiration of said first period of time, during which said first result set may be usable.

3. The system of claim 2, wherein:

a first operation involving said first cache table instance is received at a time O;

said first period of time ends at a time V;

said second period of time ends at a time U; and

said result set is usable for said first operation if:

O is earlier than V; or

O is later than V and O is earlier than U and said database is operated in the off-line mode with respect to the data source.

4. The system of claim 1, wherein said database operates in the online mode with the central data source to receive a first result set for a first cache table instance only when:

said first result set does not exist in the database; or

said first result set exists in the database, but is not usable.

5. The system of claim 1, wherein:

if a first result set of a first cache table instance is valid, said database operates in the off-line mode during an operation involving said first cache table

instance regardless of whether the wireless link to the central data source is available.

6. A system for caching data on a mobile computing device, wherein the mobile computing device is configured for connection to a central data source on a discontinuous basis, the system comprising:

a cache table configured to cache data, from the central data source, on the mobile computing device;

one or more entries in said cache table, each said entry comprising a set of data from the central data source;

for each entry in said cache table, a validity parameter for determining a period of time during which said set of data is valid;

for each entry in said cache table, a usability parameter for determining whether said set of data is usable after said period of time during which said set of data is valid; and

a communication module configured to connect the mobile computing device to the central data source on a less than continuous basis;

wherein the cache table facilitates caching of data from a data source, on a mobile computing device coupled to the data source with a discontinuously available communication link.

7. The system of claim 6, wherein said validity parameter is configured to identify a first time at which said set of data becomes invalid;

wherein, until said first time, said set of data is used for an operation involving said cache table entry, regardless of whether the mobile computing device is connected to the central data source.

8. The system of claim 6, wherein said usability parameter is configured to identify a second time at which said set of data becomes stale;

wherein, after said first time and until said second time, said set of data is used for an operation involving said cache table entry, only if the mobile

computing device is not connected to the central data source.

9. The system of claim 6, wherein said communication module is configured to connect the mobile computing device to the central data source for a maximum of one cache table entry operation at a time.

10. The system of claim 9, wherein the mobile computing device is not connected to the central data source for an operation involving a cache table entry that is valid.

11. A method of caching data on a mobile computing device, wherein the mobile computing device is connectable to a data source via a discontinuously available wireless link, comprising:

receiving a first operation involving a first set of data cached on a mobile computing device;

determining whether said first set of data is valid;

if said first set of data is invalid, determining whether said discontinuously available wireless link is available;

if said first set of data is invalid and said less than continuously available wireless link is unavailable, determining whether said first set of data is usable; and

retrieving an update for said first set of data from the data source only if:

said first set of data is invalid; and said less than continuously available wireless link is available.

12. The method of claim 11, further comprising:

determining whether said first set of data is locked by a first transaction;

wherein said first operation was initiated by said first transaction.

13. The method of claim 11, further comprising:

determining whether an active cursor is open on said first set of data by a first transaction;

wherein said first operation was initiated by said first transaction.

14. The method of claim 11, wherein said determining whether said first set of data is valid comprises:

accessing a validity parameter associated with said first set of data, wherein said validity parameter is configured to indicate a first time at which said first set of data becomes invalid; and

comparing a time of said first operation with said first time;

wherein said first set of data is valid before said first time.

15. The method of claim 14, wherein said determining whether said first set of data is usable comprises:

accessing a staleness parameter associated with said first set of data, wherein said staleness parameter is configured to indicate a second time, after said first time, when said first set of data becomes stale; and

comparing said time of said first operation with said second time;

wherein said first set of data is usable between said first time and said second time.

16. The method of claim 11, further comprising, prior to said receiving a first operation:

configuring a cache table on the mobile computing device for caching data, including said first set of data, wherein said cache table is defined by:

a set of access parameters comprising a first set of columns of a dataset on the data source; and

a second set of columns of the dataset.

17. The method of claim 16, further comprising, prior to said receiving a first operation:

generating one or more instances of said cache table, wherein each said cache table instance comprises:

an argument comprising a unique set of values for said set of access parameters; and

a result set comprising values for said second set of columns;

wherein said first set of data comprises a first result set of a first cache table instance.

18. The method of claim 16, wherein said dataset comprises one or more database tables.

19. The method of claim 16, wherein said dataset comprises one or more database views.

20. The method of claim 11, further comprising:

if said first set of data is invalid and said discontinuously available wireless link is unavailable and said first set of data is unusable, signaling an error.

21. The method of claim 11, further comprising:

using said first set of data for said first operation if:

said first set of data is valid; or

said first set of data is invalid and said less than continuously available wireless link is unavailable and said first set of data is usable.

22. A method of facilitating the caching of data from a data source, on a mobile computing device coupled to the data source with a discontinuously available communication link, comprising:

configuring a cache table within a database on the mobile computing device, wherein said cache table includes:

access parameters comprising a first set of columns of a dataset on a data source;

result columns comprising a second set of columns of the dataset distinct from the first set of columns of the dataset;

generating one or more instances of said cache table within the database, wherein each said cache table instance comprises a set of rows, wherein each said row comprises:

an argument, said argument comprising a value for each column of the access parameters; and

a result set comprising a value for each column of the result columns, wherein each row in a set of rows comprises the same argument; and

for each said cache table instance, storing one or more parameters for determining whether said result set of said cache table instance may be used for a data operation

wherein said parameters include a time-to-live parameter configured to indicate a first period of time during which said result set is valid; and

wherein said result set becomes invalid at the end of said first period of time.

23. The method of claim 1, wherein said parameters include a response date indicating when said result set was received from the data source.

24. The method of claim 1, wherein said parameters include a last modification date indicating when said result set was last modified at the data source.

25. The method of claim 1, wherein said result set is used for said data operation if said result set is valid, regardless of whether the discontinuously available communication link is available.

26. The method of claim 1, wherein a replacement result set for said result set is retrieved from the data source only if said result set is invalid.

27. The method of claim 1, wherein an update for said result set is retrieved from the data source only if said result set is invalid.

28. The method of claim 1, wherein said parameters include a staleness parameter configured to indicate a second period of time, following said first period of time, during which said result set is usable; and

wherein said result set becomes stale at the end of said second period of time.

29. The method of claim 28, wherein said result set is used for said data operation if said result set is usable and the discontinuously available communication link is not available.

30. The method of claim 28, further comprising:

receiving a first data operation, involving a first cache table instance; and using said result set of said first cache table instance if:

(a) said result set of said first cache table instance is valid; or

(b) said result set of said first cache table instance is invalid and:

(1) said result set of said first cache table instance is usable; and

(2) the less than continuously available communication link is not available.

31. The method of claim 30, further comprising:

retrieving an update for said result set of said first cache table instance only if said result set of said first cache table instance is invalid.

32. The method of claim 30, further comprising:

retrieving a replacement result set for said result set of said first cache table instance only if said result set of said first cache table instance is invalid.

33. The method of claim 30, further comprising:

signaling an error if:

said result set of said first cache table instance is invalid; said result set of said first cache table instance is stale; and the less than continuously available communication link is not available.

34. The method of claim 1, wherein said dataset is one of a database table and a view.

35. A computer readable storage medium storing instructions that, when executed by a computer, cause the computer to perform a method of facilitating the caching of data, from a data source, on a mobile computing device coupled to the data source with a less than continuously available communication link, the method comprising:

configuring a cache table within a database on the mobile computing device, wherein said cache table includes:

access parameters comprising a first set of columns of a dataset on a data source;

result columns comprising a second set of columns of the dataset distinct from the first set of columns of the dataset; generating one or more instances of said cache table within the database, wherein each said cache table instance comprises a set of rows, wherein each said row comprises:

an argument, said argument comprising a value for each column of the access parameters; and

a result set comprising a value for each column of the result columns, wherein each row in a set of rows comprises the same argument; and

for each said cache table instance, storing one or more parameters for determining whether said result set of said cache table instance may be used for a data operation

wherein said parameters include a time-to-live parameter configured to indicate a first period of time during which said result set is valid; and

wherein said result set becomes invalid at the end of said first period of time.

36. A computer readable storage medium storing instructions that, when executed by a computer, cause the computer to perform a method of caching data on a mobile computing device, wherein the mobile computing device is connectable to a data source via a discontinuously available wireless link, the method comprising:

receiving a first operation involving a first set of data cached on a mobile computing device;

determining whether said first set of data is valid;

if said first set of data is invalid, determining whether said less than continuously available wireless link is available;

if said first set of data is invalid and said discontinuously available wireless link is unavailable, determining whether said first set of data is usable; and

retrieving an update for said first set of data from the data source only if:

said first set of data is invalid; and

said less than continuously available wireless link is available.

37. A database for caching data on a mobile device, the database comprising:

a cache table defined by:

a set of access parameters corresponding to a first set of attributes of a data source accessible through a wireless communication connection; and

a second set of attributes of the data source;

wherein the database is discontinuously connected to the central data source through the wireless communication connection; and one or more instances of said cache table, wherein each said cache table instance comprises:

an argument, said argument comprising a unique set of values for said access parameters; and

a result set comprising values for said second set of attributes; and for each said cache table instance, information for determining a period of time during which said result set is usable on the mobile devices;

wherein the database facilitates caching of data from a data source, on a mobile computing device coupled to the data source with a discontinuously available communication link.

38. The database of claim 37, wherein said period of time during which said result set is usable comprises:

a first period of time during which said result set is valid.

39. The database of claim 38, wherein said first period of time is specified by the data source.

40. The database of claim 38, wherein the database is configured to not retrieve said result set from the central data source during said first period of time.

41. The database of claim 38, wherein said period of time during which said result set is usable further comprises:

a second period of time during which said result set is invalid but not yet stale;

wherein said second period of time immediately follows said first period of time.

42. The database of claim 41, wherein said result set is not usable by a database transaction after said second period time unless:

said result set is locked by the database transaction; or

the database transaction has an active cursor open on said result set.

43. The database of claim 37, wherein said information comprises:

a first parameter configured to indicate when said result set becomes invalid; and

a second parameter configured to indicate when said result set becomes stale.

44. The database of claim 37, further comprising:

a queue configured to store operations on said one or more cache table instances prior to transmission of the operations to the data source;

wherein the operations are stored in said queue when the data source is not accessible through the wireless communication connection.


Description

BACKGROUND

This invention relates to the field of computer systems. More particularly, a system and methods are provided for caching data on a mobile device.

Applications operated on mobile devices (e.g., laptop computers, personal digital assistants, mobile telephones) have generally been designed for either online or offline use. Both types of mobile applications tend to use some form of browser to interact with a user. Online applications enjoy continual access to an enterprise server (e.g., central database server). Offline applications, in contrast, operate with minimal or no contact with an enterprise server.

More specifically, an online mobile application can access data on the enterprise server whenever needed, thereby possibly obviating any need to store data locally. However, because of the "always connected" nature of an online mobile application, connection costs (e.g., for wireless air time) can be quite high.

Also, an online mobile application generally suffers from unpredictable latency. When the online application transmits a request to the server, the response time depends upon the level of usage of the mobile device's wireless network in addition to any congestion at the server. Further, usage of the online application may be geographically limited, depending on the extent of the wireless network, and may be prohibited in some locations (e.g., airplanes, hospitals).

Yet further, online mobile applications often access data in sets, such as entire web pages, data tables, etc. When a data item needs to be replaced, the entire dataset may be replaced rather than just the one item. This can be inefficient and increase the cost of operating the application.

One reason mobile applications tend to access data in sets (e.g., entire web pages), is that the data are tightly coupled to the presentation of the data. In particular, when data are copied or downloaded to a client device for a mobile application, each collection of data (e.g., a table, a set of database rows or fields) is typically conveyed within the page in which it will be displayed. Thus, the data cannot be displayed on the client except in that page. Because each set or collection of data may be stored with a full display page, and many pages may be identical except for their encapsulated data, much storage on the client may be wasted.

In contrast to an online application, an offline mobile application does not enjoy continual access to data maintained by the enterprise server. Some data (e.g., a snapshot) from an enterprise server may be copied onto or replicated on a mobile device. Although the offline application may always be usable (e.g., when offline from the enterprise server), it will not always have fresh data, and it can only access data that were copied to it.

An offline mobile application configured to use data snapshots is usually required to synchronize its stored, offline data with an enterprise server on an occasional or periodic basis (e.g., once per day). The frequency of synchronization is generally unrelated to the frequency with which data items are accessed or modified on the mobile device. Thus, many transactions or operations may be performed on the mobile device using stale data. And, synchronization may entail high overhead, as a large amount of data will often be exchanged—even data that have not changed and do not need to be refreshed. For example, an entire web page or set of web pages may be downloaded or exchanged even though only one data item in a page needs to be updated.

Because of the infrequent rate of data synchronization, offline mobile applications are not suitable for use with data that are highly dynamic. In addition, an offline mobile application is often required to maintain a transaction log of all data changes made by the application, in order to facilitate synchronization.

In general, enterprise data stored on a mobile device, for use with a mobile application, may have varying longevity. Some data points or items may be valid for long periods of time (e.g., a product description, an address); other data points or items may be invalid after only a relatively short period of time (e.g., a stock quote, a currency conversion rate). Existing mobile applications and client databases typically are not configured to recognize or consider the longevity of downloaded data.

Further, mobile client applications that attempt to provide significant functionality to users tend to require robust software and/or hardware configurations (e.g., a Java Virtual Machine, an HTTP listener, a servlet engine). Such requirements prevent the use of smaller, more restrained client devices, such as Personal Digital Assistants (PDA) or smart telephones, and also add overhead to client operations.

SUMMARY

In one embodiment of the invention, a system and methods are provided for fine-grained caching of data for use with an application executing on a mobile (e.g., wireless) device configured for use in a third generation wireless network or other enterprise network. In this embodiment, the device need not always access a central or master source of the data (e.g., a data, web or application server) and can use the cached data in an online or offline mode. Traditional synchronization operations between the device and the data source are unnecessary, as data cached on the mobile device may be selectively refreshed when needed. Thus, benefits of both modes of operation (e.g., fresh data, acceptable connection costs) are obtained.

In an embodiment of the invention, data are cached in cache tables implemented as part of a local DBMS (Database Management System) of a mobile device. In this embodiment, a cache table is a table whose content (e.g., rows) are retrieved from a server, on demand, and cached locally according to cache control instructions associated with the content. A subset of the columns (or attributes) of a cache table is designated as the "access parameters" for the cache table. To retrieve data from a cache table, a value is provided for each of the access parameters. These values constitute an argument for one instance of the cache table. If the row(s) with those argument values are not in the local database, or have expired, the DBMS will contact the corresponding server to retrieve and cache the rows.

For example, if a cache table is configured to report inventory figures for various warehouse locations in response to a specified part number, the cache table columns may include a part number, a warehouse number, and a quantity of the part stored in a corresponding warehouse. The part number, which is supplied as part of a query, may be an access parameter for the cache table. For each unique part number, a separate instance of the cache table includes a set of rows (a result set) that reports quantities of the part stored in each warehouse.

In an embodiment of the invention, data caching is separated from application logic by encapsulating data caching policies within the cache tables. This relieves application developers from having to code caching policies as part of the application logic, and permits a database administrator to define caching policies.

In another embodiment of the invention, an algorithm is provided to define the data and transactional semantics of cache tables, in a manner that is consistent with the ACID (Atomicity, Consistency, Isolation, and Durability) properties of database transactions. In particular, data stored in a cache table have associated periods of validity, which may be specified by a data source from which the data were obtained. Data may also have associated cache control information indicating whether, and how long, they may be used after becoming invalid, if no connection to the server is available. When a local database operation affects a cache table, the algorithm is applied to determine whether to use the cached data or attempt to refresh the data from the data source. The algorithm may consider whether a connection is available to the data source, whether the data are locked by the same or another transaction, whether the data are invalid, whether the associated cache control information allows the data to be used while invalid, etc.

Illustratively, an embodiment of the invention enables a mobile device and application to access local data offline, and selectively refresh specific data (e.g., cache table result sets) as needed. As a result, connection costs (e.g., to a data source) and the use of stale data are minimized. And, because the cache table is a table, all mobile database applications can reap the benefits afforded by cache tables without having to write extra code in the application logic.

DESCRIPTION OF THE FIGURES

FIG. 1 is a block diagram depicting a mobile computing environment suitable for implementation of an embodiment of the present invention.

FIG. 2 is a block diagram of a client device configured to cache data on a mobile computing device, in accordance with an embodiment of the invention.

FIGS. 3A-B comprise a flowchart illustrating one method of using and refreshing a cache table in accordance with an embodiment of the invention.

FIG. 4 depicts a mobile client device equipped with an intelligent client agent, in accordance with an embodiment of the invention.

FIG. 5A is a flowchart demonstrating a method of operating a dispatcher, within an intelligent client agent, to process a requested page, in accordance with an embodiment of the invention.

FIGS. 5B-C comprise a flowchart demonstrating a method by which a script engine may assemble a page within an intelligent client agent, in accordance with an embodiment of the invention.

FIG. 6 depicts a cache table, according to one embodiment of the invention.

FIGS. 7-11 demonstrate illustrative formats for communications between a client device operating a cache table and a data source associated with the cache table, according to one embodiment of the invention.

DETAILED DESCRIPTION

The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of particular applications of the invention and their requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art and the general principles defined herein may be applied to other embodiments and applications without departing from the scope of the present invention. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.

The program environment in which a present embodiment of the invention is executed illustratively incorporates a general-purpose computer or a special purpose device such as a mobile computer, a PDA (Personal Digital Assistant), a telephone, etc. Details of such devices (e.g., processor, memory, data storage, display) may be omitted for the sake of clarity.

It should also be understood that the techniques of the present invention may be implemented using a variety of technologies. For example, the methods described herein may be implemented in software executing on a computer system, or implemented in hardware utilizing either a combination of microprocessors or other specially designed application specific integrated circuits, programmable logic devices, or various combinations thereof. In particular, the methods described herein may be implemented by a series of computer-executable instructions residing on a suitable computer-readable medium. Suitable computer-readable media may include volatile (e.g., RAM) and/or non-volatile (e.g., ROM, disk) memory, carrier waves and transmission media (e.g., copper wire, coaxial cable, fiber optic media). Exemplary carrier waves may take the form of electrical, electromagnetic or optical signals conveying digital data streams along a local network, a publicly accessible network such as the Internet or some other communication link.

Introduction

In one embodiment of the invention, a system and method are provided for fine-grained caching, on a mobile device, of data used by an application executing on the device. In this embodiment, application data are stored in a database (e.g., a DBMS) comprising one or more cache tables configured to monitor the validity and/or usability of cached data.

In this embodiment, a cache table not only caches one or more data rows, but also stores, or is associated with, cache control information that describes the validity of the data, where or how to get a fresh copy of the data, etc. When an application accesses the cache table, the local DBMS inspects the desired data and, if still valid, serves it. If the cached data are no longer valid, the local DBMS requests updated data from the server if a connection to the server is available. Instead of retrieving a large set of data in order to update a single (invalid) data row, just that row may be retrieved.

In an embodiment of the invention, a cache table is a database table of data that can be retrieved on demand from a data source (e.g., enterprise server, database server, web server, application server), and stored in a local (e.g., mobile) device. Communications between the server and the device may employ any suitable protocol, such as HTTP (Hyper Text Transport Protocol), SOAP (Simple Object Access Protocol), WAP (Wireless Access Protocol), etc. A server hosting a data source may be configured to execute CGI (Common Gateway Interface) programs, servlets, applets, Java methods or other modules to implement interfaces associated with cache table specifications described herein.

In one embodiment of the invention, a cache table is compatible with a database programming model, so that a mobile application can access the cached data through a standard interface, such as ODBC (Open Data Base Connectivity) or JDBC (Java Data Base Connectivity). A mobile application that uses a local database of cache tables can therefore be written using a normal database model and interface. The database, through its cache table(s), manages data validity, retrieves updates for invalid data, and so on. The data and transactional semantics of cache table may be designed to follow industry standard transactional semantics.

Because the mobile device may not always be actively communicating with an enterprise server (or other central/master data source), and because data retrievals can be limited to just those data items that are invalid, connection costs can be kept relatively low. And, because of the limited number of accesses that must be made to the enterprise server, there is less of a problem with erratic performance resulting from unpredictable latency.

In another embodiment of the invention, an intelligent client agent is provided for enhancing operation of an offline application executed on a mobile computing device (e.g., a Personal Digital Assistant (PDA), a laptop or notebook computer, a smart telephone). In this embodiment, the client agent enhances the operation of the offline application by selectively enabling online access and separating application content from the presentation format of the content. Content and presentation may be separated by storing the data separately (e.g., in a cache table, snapshot or regular database table) from the presentation description or format of an application page. When an offline application needs a page, the client agent reconstructs the application page from the presentation description and data stored in the local database. The client agent may go online to retrieve volatile data and/or data that are stale; the client agent may also facilitate synchronization of a client snapshot with a server. Further, a client agent may enable a server to push information to a client cache table or database (e.g., using a push listener), and may also support voice-based interaction with a client application.

FIG. 1 depicts an illustrative mobile computing/communication environment in which an embodiment of the invention may be implemented. In this embodiment, enterprise server 150 is accessible through a direct wireless link 130 and/or network 140, which may comprise the Internet. Users of mobile devices 102a-102d therefore access server 150 directly or though a series of communication links. A user's mobile device may be a laptop or other portable computer, a PDA, a telephone, a two-way pager or other device.

In one embodiment of the invention, a client database or DBMS may include one or more snapshots of server data in addition to any cache tables. In this embodiment, a cache table stores data that may have originated anywhere (e.g., the client, any remote server or other system), along with information regarding the validity of the data. A snapshot stores data from a server or other source that is explicitly synchronized with the server. Illustratively, snapshot data may always be available when offline, while cache table may or may not be usable offline, depending on the validity of the data. Finally, regular database tables may be used store data generated by, and/or only used by, the client.

Cache Table Concepts

FIG. 2 is a block diagram of a mobile client device suitable for implementation with an embodiment of the invention. Device 200 comprises mobile application 210, database 220 and communication module 230.

Mobile application 210 is an application that uses or draws upon data stored in database 220. Database 220 may be configured to store any type of data (e.g., textual, numerical, graphical, video) for use by application 210. Database 220 includes one or more cache tables for caching the data, such as cache table 222. Database 220 also includes associated cache control information 224. Further details regarding cache tables and cache control information are provided below.

Communication module 230 is configured to access a server or data source that stores current or master versions of data cached in database 220. Thus, as described below, database 220 may periodically access the server, through communication module 230, in order to download new data, fresh data, updates to cached data, etc. Communication module 230 may be directly operated by the database, or the database may access the communication module through application 210, an operating system or other entity. Thus, communication module 230 may be coupled to mobile application 210 in addition to, or instead of, database 220.

In embodiments of the invention described herein, database 220 is a DBMS (Database Management System) product offered by Oracle® Corporation, such as Oracle 9i Lite.

In an embodiment of the invention, a cache table can be characterized by a four-tuple in the form
Cache Table Schema

In one embodiment of the invention, the schema, S, of a cache table is defined by three things: the name of the cache table, a list of column definitions describing the structure of the cache table, and a list of access parameters. A cache table name may adhere to table-naming conventions of SQL (Structured Query Language) databases.

A column definition comprises an identifier and an associated data type. Each identifier corresponds to a column name of the cache table, and may follow a column-naming convention. The access parameter list is an ordered list of a subset of the column identifiers of the cache table.

Because the cache table schema, S, describes the structure of a cache table, it also defines the structure of each instance of the cache table. In this embodiment of the invention, a cache table instance comprises all rows of the cache table that have identical values for the access parameter column(s) of the access parameters. An argument comprises a list of values—one for each access parameter of the cache table. Thus, an instance is a set of rows of the cache table with the same argument.

The result set of a cache table instance comprises a set of rows of the instance, each row comprising a list of columns that are not in the access parameters. That is, a result set is a projection of a cache table instance on the non-access parameter columns of the cache table. A specific instance of a cache table may be indicated by the name of the cache table followed by the corresponding argument value.

FIG. 6 depicts an illustrative cache table, according to one embodiment of the invention. Inventory cache table 600 includes three columns: Part# 602, Warehouse# 604 and Quantity on Hand (QOH) 606. In this cache table, the access parameter comprises just Part# 602. Thus, two arguments are shown: the values 1234 and 9876.

Based on the two arguments, two instances of the Inventory cache table are shown. One instance comprises three rows having the Part# 1234, and the other comprises two rows having the Part# 9876. The columns of cache table 600 that are not part of the access parameter form the result sets for the two instances.

In this embodiment of the invention, an illustrative cache table may be defined according to the following SQL (Structured Query Language) syntax:

CREATE CACHE TABLE
[,
[, ACCESS PARAMETERS (
USING
where
Using this illustrative SQL syntax, a sample cache table may be
defined as follows:
CREATE CACHE TABLE Inventory
(part# char(4), warehouse char(8), qty number(10),
PRIMARY KEY (part#, warehouse),
ACCESS PARAMETERS (part#))
USING InventoryTDP TYPE updateable AT MyCompanyDS;


The schema, S, of the illustrated cache table is "Inventory (part# char(4), warehouse char(8), qty number (10))." One access parameter is specified: part#. The result set for the cache table comprises a set of rows, each of which contains two columns: a warehouse identifier and the quantity of the specified part that is stored in the warehouse. Following sub-sections describe portions of this sample cache table definition in further detail.

In general, the schema for a cache table T may be written as T(a1, . . . , am, r1, . . . , rn), where T is the cache table name, a1, . . . , am is the list of access parameters and r1, . . . , rn are the cache table result set columns. Thus, the sample cache table may be represented as:
    • Inventory(part#, warehouse, qty)


  • An instance of a cache table may be written as T(v1, . . . , vm), where v1 is a value for access parameter ai. In this instance, the tuple 1, . . . , vm>constitutes the argument of a specific cache table instance, and each row of the corresponding result set is of the form 1, . . . , rn>. Each row of a result set may be considered a separate result. The term "cache table" may be used herein to refer to a cache table having a particular structure (schema), or an instance of that cache table.

    A set of instances of a cache table may be termed an "extension" of the cache table. An extension of a cache table is defined to include all instances of the cache table that are stored in the local database or DBMS. The extension of a cache table T may be written as E(T).

    For a cache table, two predicates are defined with relation to each row of its extension: isValid and isUsable. As described further below, the isValid predicate may be used to determine whether a row is valid (e.g., at the time of a query execution), while isUsable may be used to determine whether the row is usable. Illustratively, if a row is valid, then it is usable, but if it is invalid, it may or may not be usable.

    In one embodiment of the invention, a cache table may be used in multiple ways in an SQL statement. A reference to the cache table name alone (e.g., Inventory) is interpreted as a reference to the extension of the cache table. Thus, the SQL statement "Select*from Inventory" will return all rows of all result sets of all instances of the cache table Inventory that are currently stored in the local database. The local DBMS may not check for validity of usability of the rows nor make any attempt to refresh cache table instances. Illustratively, this type of reference may be limited to queries, and may not be usable for updates. It may be considered a "dirty read" of the cache table.

    A reference to a cache table that includes a full set of argument values (e.g., constants) for an access parameter will return one instance of the cache table. Thus, the statement
    • Select*from Inventory('P123')
      will return a table of "part#", "warehouse" and "qty" data for part number 'P123.' With this type of reference, the local DBMS will use the flowchart shown in FIGS. 3A and 3B (described below) to refresh the instance if needed.


  • Another reference to a cache table, within an SQL statement, may include at least one variable within the argument. If the reference (e.g., in a query) is valid (i.e., a value can be bound to the variable), this type of reference returns one or more instances of the cache table. Thus, the statement

    Select p#, partName, warehouse, qty From part P, Inventory(P.p#)

    can be used to obtain result sets of inventory for part numbers in the part table. If no values can be bound to the variable, the query is considered invalid. With this type of reference, the local DBMS will use the flowchart shown in FIGS. 3A and 3B to refresh the instances if needed.

    The preceding example demonstrates how a cache table access parameter can be bound to a column or expression of another table, including a result set of another cache table. Illustratively, a fully qualified column specification of a cache table column may use an alias for the cache table name, as in the following:

    SELECT P.p#, P.pname, Inv.qty

    FROM P, Inventory(P.p#) Inv

    WHERE Inv.qty>100

    Constraints

    In an embodiment of the invention, constraints may be defined on any cache table extension (i.e., set of cache table instances). Thus, the column list of a cache table can be used to define constraints on the cache table. For example, primary and foreign key constraints may be defined in the definitions of columns of the cache table (e.g., if they are single attribute keys), or may be defined in a Primary Key or Foreign Key clause in the constraints portion of the cache table definition.

    The sample Inventory cache table defined above includes one constraint, a primary key consisting of part# and warehouse. This means that, for a given part#, the result set may contain many rows or results, but no two rows in the result set will have the same warehouse value.

    When defining the constraints, C, of a cache table, there are several options. For example, a single primary key may be defined as a combination of all of the access parameters or as a combination of all of the access parameters and some of the result set identifiers. Illustratively, if access parameter 'part#' of the Inventory cache table was defined as a primary key for the cache table, then the data returned for a particular value of 'part#' could contain, at most, a single row. In contrast, if a primary key was defined as a combination of 'part#' and 'warehouse,' then multiple rows could be returned for a given value of 'part#,' but the values for 'warehouse' would be unique for each value of 'part#."

    For every cache table in one embodiment of the invention, a non-null system constraint is automatically defined for each access parameter. Additional constraints may be defined on an extension of the cache table. The DBMS will perform data integrity checks based on these constraints whenever a result set is received from a data source and instances are constructed from them. Integrity constraints may also be used to optimize storage of a cache table. For example, and as stated above, if a primary key is defined on any (or all) of the access parameters of a cache table, then each result set will contain at most one row for an argument, and the extension of the cache table may be stored in one physical table.

    Conceptually, a constraint on a cache table T is a constraint defined on E(T). In an embodiment of the invention, if a primary key is defined on any (or all) of the access parameters of a cache table, the DBMS may store E(T) in a single physical table. All constraints defined on that cache table may be considered constraints on E(T).

    Illustratively, refreshing a cache table instance includes retrieving the result set of the instance from the corresponding TDP (Table Data Processor—described below) of a data source, creating a row from the argument for each result, and inserting the row in E(T). Constraint checking may be conducted in a normal manner for insert, delete and update operations on E(T).

    When a cache table has a foreign key referring to a primary key that comprises an entire argument of another cache table, the DBMS may check the foreign key constraint by opening a cursor on the instance of the second cache table. If the instance exists, and is valid or locked, then the constraint is deemed satisfied. If the instance does not exist, or is invalid, then the DBMS will try to retrieve or refresh the result set from the data source. If the data source returns a result, it is cached and the constraint is deemed satisfied. If there is no connection to the data source, an error is reported.

    Operations

    In an embodiment of the invention, the operations, O, that are supported for a cache table may be defined in a "Using" clause of the cache table definition. Illustratively, a Using clause may specify: the name of a data source, the name of a table data processor (TDP), and the type of the TDP.

    Implementations of cache table operations reside on a server or other location that hosts a data source and is regularly accessible to the mobile application. The implementations are invoked by the local DBMS when the corresponding operations are performed on a cache table. Alternatively, some operation implementations may reside on the mobile device.

    In one embodiment of the invention, a Using clause portion of a cache table creation may employ the following SQL syntax:

    USING
    TYPE {read-only | updateable | insertable | deletable}

    AT
    In this embodiment of the invention, two types of TDPs are supported: read-only and modifiable. A modifiable TDP may be any combination of insertable, deletable, and updateable. An insertable TDP allows rows to be inserted into the cache table extension and implements the insert method that the local DBMS will call after rows have been inserted into the cache table instance. Similarly, a deletable TDP implements the delete method and allows rows to be deleted from the cache table, and an updatable TDP implements the update method and allows rows to be updated (e.g., to change column values). As stated above, a TDP models an operation that can be performed on a cache table.

    Illustratively, a read-only TDP implements the "select" method only, which takes an argument (i.e., set of values for a cache table's access parameters) and returns a set of rows comprising a result set. A protocol that may be used is described in a following section.

    In contrast, a modifiable TDP must implement "insert," "delete" and/or "update" methods, depending on the type of the TDP declared in the corresponding Using clause, as well as the "select" method. In an embodiment of the invention, when a client device or application attempts to update a cache table, the local database first determines whether the content is still valid (as described below). If valid, the contents are updated and the corresponding method on the TDP is invoked. If the method returns a failure, the update is rolled back to the point before the operation started. If the contents were invalid, the database sends a request (e.g., insert, delete, update) to the TDP and indicates that a new result set should be returned.

    The "data source name" field refers to a data source that may be separate from the local database. A data source is configured to provide sufficient information to the local DBMS to enable the DBMS to understand the capabilities and protocol(s) of the source. A data source may also specify a period of validity and/or usability of a result set of a cache table instance. Illustratively, a data source may comprise a web server, an application server, a database server or other source.

    A data source may implement one or more TDPs; each TDP provides one or more methods to facilitate operations, on the data source, on behalf of the cache table. In this embodiment of the invention, each TDP is responsible for supplying the result set of a cache table instance when called by the client DBMS. A TDP may implement logic to perform insertions, deletes, updates, and/or other operations.

    In association with the sample cache table creation described above (cache table "Inventory"), a data source may be defined using the following extended SQL syntax:
     TYPE
     [
     
     where
     
     
     
      name> } {IDENTIFIED BY | PASSWORD}
     

    The "data source name" field will be unique within a database schema.

    The data source TYPE field defines the capability of the data source (e.g., local, basic, auth, database).

    Illustratively, a "local" data source may be a data server implemented on the client (mobile) device, and may be used to access a PIM (Personal Information Management) database, electronic mail, address book, etc. A local DBMS may preload a local data source for a given client device. In this embodiment, the protocol employed for a local data source (specified in the "protocol name" field above) is OMC (Oracle Mobile Client).

    A "basic" data source is a simple data source that can accept http, a web service request, or a similar request. It is generally a session-less server, and may not authenticate a requestor or support transactions. Therefore, the
    In this embodiment, an "auth" data source is a data source that requires client authentication (e.g., the client must login and obtain a session object). The
    A "database" data source is an authenticating data source that may support database operations such as "beginTransaction," "prepareToCommit," "commit" and "rollback." The data source may be transactional if the server hosts at least one TDP that supports cache table updates (e.g., insertion, deletion or update of rows in the cache table).

    In connection with the cache table creation illustrated above, the data source MyCompanyDS that was identified in the Using clause of the cache table creation may be defined as follows:

    CREATE DATA SOURCE MyCompanyDS

    TYPE basic PROTOCOL http

    AT 'MyCompany.com/DS';

    Protocol

    In an embodiment of the invention, the protocol(s) for communicating between a local DBMS and a data source or TDP are defined in part P of a cache table's four-tuple. In particular, P identifies one or more protocols (e.g., SOAP, HTTP, etc.), plus XML tags or other devices (e.g., HTML tags) used in a response from a data source or TDP.

    The client DBMS may communicate with the data source using any one of the supported protocols. Regardless of the protocol used, in one embodiment of the invention the client DBMS may exchange any or all of the data items of TABLE 1 with the data source.
    TABLE 1
    Operation Send Data Receive Data
    Login User name, password Session id
    Logout Session id None
    Begin transaction Session id Transaction id
    Prepare to commit Transaction id OK or ABORT
    Commit Transaction id OK
    Rollback Transaction id OK
    Select (multiple An XML document (see An XML document
    instances may be FIG. 8 for an illustrative (see FIG. 7 for an
    selected in a request) Select request document illustrative response
    format) document format)
    Insert (multiple rows An XML document (see An XML document
    of a result set may be FIG. 9 for an illustrative (see FIG. 7 for an
    inserted for a single Insert request document illustrative response
    instance) format) document format)
    Delete (multiple rows An XML document (see An XML document
    of the result set may FIG. 10 for an illustrative (see FIG. 7 for an
    be deleted for a single Delete request document illustrative response
    instance) format) document format)
    Update (multiple rows An XML document (see An XML document
    of the result set may FIG. 11 for an illustrative (see FIG. 7 for an
    be updated for a single Update request document illustrative response
    instance) format) document format)


    If the protocol used is HTTP, the argument of a cache table instance may be sent in an XML document as part of the POST method. The result of the select method may be an XML (Extensible Markup Language) document containing a header and a body. The header may contain cache control information, and the body may contain a set of rows that constitute the result set. Illustratively, the body may be encoded as an XML document according to the OMC Cache Table Result Set format, or it may be encoded as a more compact Oracle Lite CSV (Comma-Separated Values) file.

    The insert and delete methods may accept an argument (i.e., set of access parameter values) and a list of column values representing a single row that the client wants to, or previously did, insert into the cache table. The update method may take the argument and a list of column values that represent a single old row, and another list that represents an update. All the data for all the methods are sent as an XML document with the HTTP POST method.

    In one embodiment of the invention, the request format is an HTTP POST request and the URL used is that of the data source. The user agent string is "Oracle Lite". So for example, an HTTP request to obtain the instance of Inventory cache table for the argument 'p123' may be as follows:
    POST http://MyCompany.com/DS\r\n content-length: ....\r\n
    User-Agent: Oracle Lite \r\n ...
    \r\n\r\n
    .....