Tandem and Teradata have demonstrated that the same architecture can be used successfully to process transaction-processing workloads as well as ad-hoc queries. Running a mix of both types of queries concurrently, however, presents a number of unresolved problems. The problem is that ad-hoc relational queries tend to acquire a large number of locks (at least from a logical viewpoint) and tend to hold them for a relatively long period of time, (at least from the viewpoint of a competing debit-credit style query). The solution currently offered is “Browse mode” locking for ad-hoc queries that do not update the database. While such a “dirty_read” solution is acceptable for some applications, it is not universally acceptable. The solution advocated by XPRS, is to use a versioning mechanism to enable readers to read a consistent version of the database without setting any locks.While this approach is intuitively appealing, the associated performance implications need further exploration. Other, perhaps better, solutions for this problem may also exist.
A related issue is priority scheduling in a shared-nothing architecture. Even in centralized systems, batch jobs have a tendency to monopolize the processor, flood the memory cache, and make large demands on the I/O subsystem. It is up to the underlying operating system to quantizeand limit the resources used by such batch jobs in order to insure short response times and low variance in response times for short transactions. A particularly difficult problem, is the priority inversion problem, in which a low-priority client makes a request to a high priority server. The server must run at high priority because it is managing critical resources. Given this, the work ofthe low priority client is effectively promoted to high priority when the low priority request is serviced by the high-priority server. There have been several ad-hoc attempts at solving this problem, but considerably more work is needed.