Demo Data from SIGIR 2026 / reviewers in the wild / expert
Larry Brown
dblp:34/1138
· DBLP profile ↗
3ranked-venue papers
2as first author
0since 2021 · last 2002
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Systems, architecture and hardware · 1 · 1 first-authorSoftware engineering, systems software and programming languages · 1 · 1 first-authorDatabases, data management, data science and information retrieval · 1
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.
| Databases, data mining, and information retrieval
1 paper |
Distributed and cloud data management · 56% Indexing and storage engines · 44% |
Topics — the 3 heaviest of 3, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Indexing and storage engines › caching
database caching |
0.0 | 1 | 2002 | DBCache: database caching for web application servers · SIGMOD Conference 2002 |
Distributed and cloud data management › database middleware
middle-tier database caching |
0.0 | 1 | 2002 | DBCache: database caching for web application servers · SIGMOD Conference 2002 |
Distributed and cloud data management
distributed query processing |
0.0 | 1 | 2002 | DBCache: database caching for web application servers · SIGMOD Conference 2002 |
Methods — techniques the papers use, named apart from their topics
query partitioning · 0.0federated database · 0.0
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2002 | DBCache: database caching for web application serversabstractMany e-Business applications today are being developed and deployed on multi-tier environments involving browser-based clients, web application servers and backend databases. The dynamic nature of these applications necessitates generating web pages on-demand, making middle-tier database caching an effective approach to achieve high scalability and performance [3]. In the DBCache project, we are incorporating a database cache feature in DB2 UDB by modifying the engine code and leveraging existing federated database functionality. This allows us to take advantage of DB2's sophisticated distributed query processing power for database caching. As a result, the user queries can be executed at either the local database cache or the remote backend server, or more importantly, the query can be partitioned and then distributed to both databases for cost optimum execution.DBCache also includes a cache initialization component that takes a backend database schema and SQL queries in the workload, and generates a middle-tier database schema for the cache. We have implemented an initial prototype of the system that supports table level caching. As DB2's functionality is extended, we will be able to support subtable level caching, XML data caching and caching of execution results of web services. Mehmet Altinel, Qiong Luo 0001, Sailesh Krishnamurthy, C. Mohan 0001, Hamid Pirahesh, Bruce G. Lindsay 0001, Honguk Woo, Larry Brown |
SIGMOD Conference | 8 |
| 1995 | Snooping fault-tolerant distributed shared memories
Larry Brown, Jie Wu 0001 |
J. Syst. Softw. | 1 |
| 1994 | Dynamic Snooping in a Fault-Tolerant Distributed Shared MemoryabstractDistributed shared memory (DSM) allows multicomputer systems with no physically shared memory to be programmed using a shared memory paradigm. However, as the number of nodes in a system increases the probability of a failure that can corrupt the DSM increases. This paper presents a fault-tolerant DSM (FTDSM) algorithm that can tolerate single node failures. Each page in the DSM is assigned a snooper that keeps a backup copy of the page and can take over if the page owner fails. The snooper is dynamic because the responsibility for snooping a page can migrate front node to node. The FTDSM presented is an improvement over other FTDSMs because it is scalable, is based on the efficient dynamic distributed manager (DDM) DSM algorithm, does not require the repair of a failed processor to access the DSM, and does not query all nodes to rebuild the state of the DSM. It is shown that any single node failure can be tolerated because either the owner or the snooper of a page can always be found.> Larry Brown, Jie Wu 0001 |
ICDCS | 1 |