design-patternsarchitecturetransactionsdatabaseobject-oriented-database

Task vs Transaction - any practical difference?


Is there any practical difference between the term "task" and "transaction" in software engineering?

A bit of web searching yields results that are too specific to CICS. While my area of concern is in Database Management Systems (graph databases, object databases etc), the more widely applicable the answer the better.


Solution

  • The term “task” is widely applicable to a number of concepts in software engineering, following just a few of its meanings:

    1. On the most high level, a task simply is something that is to be done
    2. In concurrent programming, tasks are typically units of execution. Be it a process, a thread or something in a batch job.
    3. Specific frameworks may use the term even more specialized. For example, in the Seaside Web Framework (written in Smalltalk), a task is (roughly spoken) a web site that behaves like a wizard in desktop computing.

    On the other hand, the term “transaction” almost always conveys its database semantics (except for domain-specific meaning, of course, eg, financial transactions in accounting software). Hence, a transaction typically can be started, committed, and aborted sometimes restarted.

    Transactions can be used for concurrent programming, like the task in the sense of (2). The typical example for this is Software transactional memory, where this behavior is explicit. The GemStone/S OODB is exactly that: A database that at the same time is a software transactional memory implementation. Here, a task and a transaction virtually are the same.