Demo Data from EDBT 2026 / reviewers in the wild / expert
Robert Smeikal
dblp:79/1086
· DBLP profile ↗
1ranked-venue papers
1as first author
0since 2021 · last 2003
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 1 · 1 first-author
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Computer architecture, parallel and distributed computing, and storage systems
1 paper |
Distributed systems · 100% |
Topics — the 3 heaviest of 4, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Distributed systems › replication › replica control
asynchronous replication |
0.0 | 1 | 2003 | Fault-tolerance in a Distributed Management System: a Case Study · ICSE 2003 |
Distributed systems
fault tolerance |
0.0 | 1 | 2003 | Fault-tolerance in a Distributed Management System: a Case Study · ICSE 2003 |
Distributed systems
replication |
0.0 | 1 | 2003 | Fault-tolerance in a Distributed Management System: a Case Study · ICSE 2003 |
Methods — techniques the papers use, named apart from their topics
two-layer architecture · 0.0component-based software engineering · 0.0
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2003 | Fault-tolerance in a Distributed Management System: a Case StudyabstractOur case study provides the most important conceptual lessons learned from the implementation of a Distributed Telecommunication Management System (DTMS), which controls a networked voice communication system. Major requirements for the DTMS are fault-tolerance against site or network failures, transactional safety, and reliable persistence. In order to provide distribution and persistence both transparently and fault-tolerant we introduce a two-layer architecture facilitating an asynchronous replication algorithm. Among the lessons learned are: component based software engineering poses a significant initial overhead but is worth it in the long term; a fault-tolerant naming service is a key requirement for fail-safe distribution; the reasonable granularity for persistence and concurrency control is one whole object; asynchronous replication on the database layer is superior to synchronous replication on the instance level in terms of robustness and consistency; semi-structured persistence with XML has drawbacks regarding consistency, performance and convenience; in contrast to an arbitrarily meshed object model, a accentuated hierarchical structure is more robust and feasible; a query engine has to provide a means for navigation through the object model; finally the propagation of deletion operation becomes more complex in an object-oriented model. By incorporating these lessons learned we are well underway to provide a highly available, distributed platform for persistent object systems. Robert Smeikal, Karl M. Göschka |
ICSE | 1 |