Database Reference
In-Depth Information
A domain expert defines the following constraints: (C1) Account data has to be
accessed under strong consistency to obviate inconsistent states and (C2) Do not
schedule requests for normal customers, if there are pending requests from pre-
mium customers. How can a scheduler developer implement these constraints?
Constraint C1 can be realized with standard DBMSs by applying a high isola-
tion level, but C2 is not supported by standard DBMSs. The alternative is to
develop a new scheduler from scratch which is expensive and error-prone.
2 Smile: Declarative Scheduling Middleware
Smile, our declarative scheduling middleware prototype, allows the implemen-
tation of domain-specific scheduling constraints. Executable scheduling proto-
cols are specified with few lines of code, paving the way for sophisticated and
easy-to-reason-about scheduling protocols. Our approach is based on a generic
formal framework called Oshiya 1 that models the scheduling state as a set of
so-called scheduling relations , e.g., one relation stores the schedule produced so
far. Scheduling logic is encapsulated in a set of declarative queries called schedul-
ing queries . To produce a schedule (sequence of scheduling relation states), Smile
schedules multiple requests at the same time by repeatedly executing the schedul-
ing queries over the scheduling relations.
This approach has several advantages: (1) Smile abstracts from low level
scheduling details that are independent of the scheduling constraints such as
parallelism in the scheduler code, queueing of incoming requests, or managing
(network) connections. Developers can focus on the protocol implementation
(the scheduling queries) itself, which decreases the amount of code and the ef-
fort needed to implement or adapt schedulers. We developed scheduling queries
for the strong two-phase locking (SS2PL) protocol [4] as well as for a data depen-
dent, relaxed consistency protocol. (2) Smile's underlying model allows to specify
scheduling protocols close to their formal definition, facilitating reasoning over
properties of protocol implementations such as verifying their correctness. For
instance, we have proven the correctness of the scheduling queries implementing
SS2PL [4]. (3) The separation of scheduling logic and scheduler implementation
opens up interesting optimization opportunities that we plan to investigate in fu-
ture work. E.g., using specialized execution engines to execute scheduling queries
and controlling the trade-off between the time spent for scheduling requests and
the time spent to execute them. (4) Scheduling sets of requests at the same time
can improve the performance for large numbers of concurrent requests [3].
2.1 Oshiya Scheduling Model
In Oshiya [3], the scheduling state (requests to schedule and history information
needed for scheduling decisions) is stored in three scheduling relations: Pendin-
gRequests (
R
) buffers requests that have to be scheduled for execution. Relevan-
tHistory (
H
) stores prior executed requests in their execution order, modelling
1 Oshiya refers to the passenger arrangement staff at Japanese train stations who help
to fill a train by pushing people onto the train or guiding people to free railway cars.
 
Search WWH ::




Custom Search