Pat Helland
Abstract
We think of computation in terms of its consequences. The big MapReduce job returns a large result. Web interactions display information. Enterprise applications update the database and return an answer. These are the reasons we do our work. What we rarely discuss are the side effects of doing the work we intend. Side effects may be unwanted, or they may actually cause desired behavior at different layers of the system. This column points out some fun patterns to keep in mind as we build and use our systems.
- Gray, J., Reuter, A. 1993. Distributed Transaction Processing: Concepts and Techniques. Morgan Kaufmann. Google Scholar
Digital Library
- Haerder, T., Reuter, A. 1983. Principles of transaction-oriented database recovery. ACM Computing Surveys 15(4): 287. Google ScholarDigital Library
- Helland, P. 2012. Idempotence is not a medical condition. acmqueue 10(4). Google ScholarDigital Library
- Weikum, G., Schek, H.-J. 1991. Multi-level transactions and open nested transactions. Data Engineering 14(1): 60-64. Google ScholarDigital Library
Recommendations
Epistemic Side Effects: An AI Safety Problem
AAMAS '23: Proceedings of the 2023 International Conference on Autonomous Agents and Multiagent SystemsAI safety research has investigated the problem of negative side effects -- undesirable changes made by AI systems in pursuit of an underspecified objective. However, the focus has been on physical side effects, such as a robot breaking a vase while ...
Detecting and exploring side effects when repairing model inconsistencies
SLE 2019: Proceedings of the 12th ACM SIGPLAN International Conference on Software Language EngineeringWhen software models change, developers often fail in keeping them consistent. Automated support in repairing inconsistencies is widely addressed. Yet, merely enumerating repairs for developers is not enough. A repair can as a side effect cause new ...
Comments