Re: Transaction Oriented Architecture (TOA)

H. S. Lahman wrote:
<snip>
I would point out that your notion of 'transaction' is different than that of the typical RDBMS. The need for, content of, and timing of audit transactions is driven solely by the problem domain. OTOH, the notion of 'transaction' in the database is related to providing scope for data integrity _within the database_ when queries are processed. (Alas, 'transaction' is one of those terminally overloaded words in the computing space.)
The overloaded use of "transaction" is unfortunately but hard to avoid, which is why I tried to define how I was using it. You're correct that the term's multiple meanings can be confusing, but they aren't necessarily incompatible--or at least in practice a transaction used for auditing purposes and as a means to implement a domain's API to the database is typically encapsulated within a database transaction intended to guarantee that committed operations are indeed either all-the-way or none-of-the-way and nothing in-between.

One of the problems of synchronizing problem solutions to databases is providing mapping between such disparate notions, which segues to...

In the article I propose the impedance mismatch between Object Oriented Languages can Relational Databases can be easily eliminated. All we have to do (as OO programmers and designers) is stop pretending the database doesn't exist.

I don't think the issue is ignoring the database; it is recognizing that the database is a different subject matter applying different business rules than the problem solution. Enter stage left, dancing: separation of concerns and decoupling through subsystem encapsulation.

There is nothing to prevent abstracting the database subject matter in a classic OO manner with objects like Schema, Table, Tuple, and Query. One can provide behaviors to deal with database-specific mechanics like the construction of SQL strings. One can easily provide optimizations tailored to the database paradigm de jour. One just has to realize that problem one is solving in accessing a database is different than the problem the application is solving for the customer (at least outside the CRUD/USER arena).
But that abstraction is exactly the busywork I think that can most-often be avoided. Admittedly, in our own application (and other's I've been a party to) we have abstracted tuples--but only as a mechanism for making an RDB's answer (projection) easily accessible by making its manipulation idiomatic to the programming language. For example, using structures in C or instances in Smalltalk.

It seems to me the article was most of the way there when it proposes things like isolating SQL so it is not embedded in the problem solution and emphasizing low coupling between modules. It just didn't say specifically that one needs to encapsulate database access in a subsystem behind an interface to do that. B-)
It did quit a little early (more is planned--specifically what it looks like in code) but the primary abstractions it will propose have to do with making procedure calls idiomatic and explicit rather than abstracted and implicit (hidden). I'm of the opinion that the more obvious the database (or at least its interface) is the more easily maintainable an application becomes. I've nothing against creating frameworks and patterns to facilitate those programming activities, but prefer the concept of a problem domain transaction to language-specific expressions mapping 1:1 (or some other low-ratio) with anything physically present in the database (like tables, views, or the columns in each). From this perspective, the only mapping TOA endorses is between a procedure's answer and the language's idiomatic expression of it.

--
Visit <http://blogs.instreamfinancial.com/anything.php> to read my rants on technology and the finance industry.
.

Relevant Pages

  • Re: Help - Timing Logic
    ... server application, both of which ran on the same box. ... the client applications and 'lodging' them in the database. ... Another part of the server application was dedicated to retrieving messages ... commit transaction ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Help - Timing Logic
    ... put a trigger on the database table. ... Transaction and Database Locking - look at isolation levels / settings ... Maybe implement a message broker ... ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Help - Timing Logic
    ... build a trigger on the database .. ... Transaction and Database Locking - look at isolation levels / settings ... If you need to implement a locking mechanism / or / logging mechanism / or / a checking mechanism to avoid duplicate messages caused by multi-threading ... ... message broker gets all the necessary messages or message id's from the database to be sent ... ...
    (microsoft.public.dotnet.languages.vb)
  • Re: cdt glossary 0.1.1 [Transaction]
    ... For database purposes, when Codd's information principle and the closed-world assumption are followed I also fail to see the need for a word like "state". ... If all I wanted to do was to add 5 to x and then multiply by 4, I would expect my programming environment to give a single statement to the dbms, not two. ... Perhaps, but the updates above are pretty simple, how would you deal with a transaction consisting of multple updates where the tuples targeted by each overlap? ... Any dbms that allows a programmer to introduce an inconsistency should be recalled. ...
    (comp.databases.theory)
  • Re: Help - Timing Logic
    ... put a trigger on the database table. ... Transaction and Database Locking - look at isolation levels / settings ... Maybe implement a message broker ... ...
    (microsoft.public.dotnet.languages.vb)