Electrical computers and digital processing systems: multicomput – Remote data accessing – Accessing a remote server
Reexamination Certificate
1997-06-11
2002-07-16
Luu, Le Hien (Department: 2152)
Electrical computers and digital processing systems: multicomput
Remote data accessing
Accessing a remote server
C709S216000, C709S217000
Reexamination Certificate
active
06421715
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to computer software, and more specifically to client-server computer software.
BACKGROUND OF THE INVENTION
Where a single repository of data is shared by many users, a client-server architecture may be adopted. Referring now to
FIG. 1
, four computers
110
,
112
,
114
,
116
arranged using a client-server architecture are illustrated. In a client-server architecture, a server
110
is used to access a data repository storage device
102
that stores the data that is shared among the clients
112
,
114
,
116
. Clients
112
,
114
,
116
can request the data from the server
110
, process data, provide data to the server
110
and change data stored in the storage device
102
attached to the server
110
. Users of the client-server system
100
use a client
112
,
114
,
116
to communicate with the server
110
to access the shared data stored in the storage device
102
. Clients
112
,
114
,
116
do not have direct access to the data in the storage device
102
, but may request that the server
110
perform actions such as performing queries, or adding to or changing the data stored in the storage device
102
.
Each client
112
,
114
,
116
is coupled to the server
110
by a connection
122
,
124
,
126
between the clients
112
,
114
,
116
and the server
110
. Each connection
122
,
124
,
126
may be physically separate as shown in
FIG. 1
, or may be shared using a local area network, or LAN. Ports
142
,
144
,
146
in each of the clients
112
,
114
,
116
and associated cabling provide the OSI layers
1
-
2
connectivity between the ports
132
,
134
,
136
of the server
110
. If the server
110
will communicate with each client
112
,
114
,
116
over a LAN, a single LAN interface port may physically replace ports
132
,
134
,
136
, and ports
132
,
134
,
136
are treated as logical ports.
As the user of each client
112
,
114
,
116
performs work, the client
112
,
114
,
116
will send commands to the server
110
, and some of the commands will cause the server
110
to send data to the requesting client
112
,
114
,
116
. Each command that is sent to the server
110
requires resources from the server
110
to process the command. Commands that request data not only require the server
110
to process the command, but also to obtain the data from the data storage
102
and transmit it to the requesting client.
A conventional client
112
,
114
,
116
obtains data from the server using a request, such as a conventional query execute command. A conventional query execute command describes the data to be retrieved using a user command such as the following command, which selects the first, last, sex and department fields from an employee table for all employees having a department field equal to “ENGINEERING”:
select emp_first, emp_last, emp_sex, emp_dept
from_employee
where emp_dept=‘ENGINEERING’ (Query 1)
The client
112
,
114
or
116
formats the query execute command to include the select command above in a format required by the server and passes it to the server
110
in the form of a query execute command. The server executes the query and sets up pointers to the results in a storage area of the server
110
such as memory or hard disk. In the conventional Oracle 7 product, this area is known as an evaluation tree, and the evaluation tree is pointed to by a cursor, described below. The use of an evaluation tree and a cursor allow the query result to be rapidly retrieved from the storage device
102
a portion of the table at a time.
The data pointed to by the cursor is logically arranged as a table, with data related to each of the records described by the query corresponding to a row, and each of the fields described by the query corresponding to a column. Referring now to
FIG. 2
, sample results of the execute command including the select statement shown in Query 1 above are shown in table
210
, with columns
212
,
214
,
216
,
218
corresponding to the first and last names, sex and department, respectively, and rows
220
-
230
corresponding to individual records described by the query. The data in table
210
need not be physically arranged as shown, but may be referred to and transmitted logically as shown.
Referring now to
FIGS. 1 and 2
, commands sent from the client
112
,
114
,
116
to the server
110
direct the server
110
to transmit to the client
112
,
114
or
116
some or all of the table result
210
pointed to by the cursor. Using the query execute command, the client
112
,
114
,
116
can direct the server
110
to not only execute the query, but also to provide a portion of the results to the requesting client
112
,
114
, or
116
. Additional portions of the result are requested by the client
112
,
114
or
116
using a “fetch” command, which causes the server
110
to fetch a specified amount of data from the storage device
102
and transmit it to the requesting client
112
,
114
,
116
.
Using this execute-fetch approach, the client
112
,
114
,
116
can develop the query, have it executed by the server
110
, yet accept only a desired amount of the results of the query at a time. If the initial portion of the results of the query are not sufficient to the user of the client
112
,
114
,
116
, the user may not wish to see the remainder of the query results, saving transmission to the client
112
,
114
,
116
of the remainder of the unwanted result. Alternatively, if the user wishes to see or process additional data from the query result, the client
112
,
114
,
116
can request it using one or more subsequent fetch commands, with each fetch command retrieving a specified number of rows
220
-
230
of the table
210
.
The ability to receive only a portion of the table result saves the server
110
the overhead of passing the entire table result for a query that the user may discard. Another benefit to the execute—fetch command arrangement is that query table results which are larger than the storage capacity of the client
112
,
114
,
116
may be processed by the client a portion at a time.
Because the details of the execute and fetch commands may be cumbersome to a user, application software in each client
112
,
114
,
116
handles building the execute and fetch commands in response to indications made by the user to the user interface of the application software in the client
112
,
114
,
116
. It is possible for the application software to manage the fetching process in a manner that is transparent to the user. The user believes that all of the table result is available in the client
112
,
114
,
116
and is unaware of the actual location of the query table result being displayed.
While the execute—fetch system provides some of the benefits described above to the clients
112
,
114
,
116
, it can impose significant drawbacks on the server
110
. The overhead required for the server
110
to perform each of the many fetches which may be required can be significant. The retrieval of the result from the storage device
102
, which may be one or more conventional hard disks, requires heads to be repositioned to the proper sector, a relatively time consuming task. While disk caching systems can alleviate some of the head repositioning delay, if hundreds of users will access data relatively infrequently, the benefits from disk caching may be reduced unless the cache is relatively large, increasing its cost. Furthermore, even with a caching mechanism, the processor in the server
110
must still receive and process the fetch request for data. This processing can be substantial. For example, the processing can require the operating system to schedule the process that needs to process the call and this overhead can be quite high. Then, one or more subroutines must be called, which slow the processors in the server
110
from servicing the other clients
112
,
114
,
116
which share the server
110
. Thus, receiving and processing fetch requests can require substantial processing overhead and this
Chatterjee Debashish
Chidambaran Lakshminarayanan “Luxi”
Lari Mohammad S
Gotlieb Charles E.
Innovation Partners
Luu Le Hien
Oracle Corporation
LandOfFree
System and method for generating and transmitting a command... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for generating and transmitting a command..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for generating and transmitting a command... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2901826