TU München - Fakultät für Informatik Lehrstuhl III: Datenbanksysteme

Monitoring the Progress of Query Execution

The execution of an ObjectGlobe query can fail for a variety of reasons: network failures, crashed servers, badly programmed external operators, extremely overloaded servers, etc. Without precautions such failures can lead to live- or deadlocked query execution plans, in which upper-level query operators wait indefinitely for blocked sub-plans to deliver their results. Therefore, it is important to monitor the progress of the query execution and inform the participating ObjectGlobe servers about failures.

Each ObjectGlobe server uses a dedicated thread (we call it the monitor thread) for detecting blocked queries. A monitor thread operates on a data structure, which is organized as a priority queue. The objects stored in this queue represent future points in time and the object with the closest point in time has the highest priority. Such an object (we call it a timeout object) specifies an event inside a query, which has to occur in that query until the specified point in time has been reached. If its time has come, the monitor thread removes the timeout object out of the queue and checks if the associated event has occurred. If this is the case, the object is discarded and nothing else happens. Otherwise the affected sub-plan of the query is assumed to be blocked and it is terminated by a special terminator thread. When a sub-plan is stopped due to an error condition in an operator, the ObjectGlobe servers, executing the operators beneath and above the failed one in the plan hierarchy will be informed about this fact. The sub-plans of the operators beneath will normally fail. The operators above could react to the failure in special ways (also fail, rearrange the plan, execute an alternative sub-plan, etc. [CD99]). The propagation of an error up the hierarchy is performed by the standard exception handling mechanism of Java with a little help from our send-/receive operator pair for crossing network connections. The servers of child operators cannot be informed with the exception mechanism. A special (UDP) network protocol is used for this purpose.

Figure 10: The Architecture of the Monitor Component.

What we did not mention up to now is, where the timeout objects come from. These objects are created by a special type of operator, a monitor operator. A monitor operator can be inserted at arbitrary positions in a query evaluation plan, since it does not change its input tuple stream. Positions where we will always insert monitor operators are above receive operators and above any external operator. Its job is to observe the progress of the actions performed by the sub-plan beneath it. For example, at the beginning of its open method a monitor operator creates a timeout object for the event ``end of open reached'' and inserts this object into the priority queue of the monitor thread, while also keeping a reference to that object. After that, the open method of its child operator is called. When the method invocation returns, the timeout object is informed, that its awaited event has occurred.

The advantage of this architecture is that the decisions about where to monitor in a query evaluation plan and with what parameters the timeouts should be initialized can be made in a flexible manner. Setting timeouts is critical, just as in any other system. One option is to set the timeout based on the response time estimates of the optimizer. Another option is to use a default value. Other operators and especially external operators need not implement anything for the monitor component. An overview of this architecture is given in Figure 10.