Re: Object Oriented Concurrency

Responding to frebe...

Yet another case where OOP fails to learn/use the lessons of databases
(and would morph into a database if it did).
ROFL.
The mind boggles, so I'll bite. Please explain what techniques a DBMS
engine employs for concurrency that are not readily available to OO
application developers and were not already in use in R-T/E before the
first DBMS was invented.
Sure, it's available, but has to be added and integrated with effort.
And like I said, the more DB features you add, the more it morphs into
a (hacked up) DB. Thus, you are not competing with a DB, but rather
becoming one.
But concurrency has nothing to do with DBMS features; it is fully
orthogonal.

Mainstream DBMS:es has many features for supporting concurrency. But
the relational model is orthogonal to concurrency features.

You are talking about the external manifestation of a specific concurrency design model used within the DBMS engine. That manifestation happens to be tailored expressly to the RAD CRUD/USER realm. Those features only have value when managing data storage. They are patently useless for something like R-T/E and large applications where one must organize behaviors.


Note that a DBMS engine is just another application; the only thing
different is the problem space. It can be designed with OOA/D,
Structured design, or functional design. And each design approach will
manage concurrency consistently within that paradigm for that problem space.

The big difference is that there are many successful relational DBMS
engine implementations out there, availible for you. Using the OO
approach, you have to re-invent the wheel by yourself, or use a OO/
network database which has many known disadvantages compared to
relational databases.

If I were building an application that had to use a DBMS for persistence I would certainly not reinvent the DBMS to do so. I would happily use every convenient feature the DBMS provided for accessing RDB storage. I would also happily leave the problems of multiuser concurrency (i.e., applications besides mine) to the DBMS facilities. So there is no wheel reinvention required.

What I would not do is try to solve the customer problem using P/R techniques or try to resolve complex processing concurrency issues, that arise when optimizing my solution, using DBMS concurrency features that were designed for multiuser data access. Instead I would encapsulate the persistence access in a single subsystem so that only that subsystem needed to understand the highly specialized RDB paradigm.


For example, things like two-phase commit in a DBMS are simply the
outward manifestation of resolving concurrency in the DBMS engine for an
RDB problem space. IOW, if one isn't solving the problem in an RDB
context, one doesn't need two-phase commit and concurrent processing
would be manifested differently.

In what way are two-phase commit a problem unique to relational
databases?

It is unique to multiple users attempting to access stored data. If that is not the problem you are solving, then it is pretty useless. [There are variants that are useful in other synchronization contexts like handshaking protocols. But they will typically be tailored to other techniques, such as interacting state machines rather than a notion of 'transaction'.]


--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer

H. S. Lahman
H.lahman@xxxxxxxxxxx
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html
.

Relevant Pages

  • Re: Object Oriented Concurrency
    ... the relational model is orthogonal to concurrency features. ... Obviously concurrency features in a DBMS only have value when managing ... Large applications outside the CRUD/USER realm *use* data but they don't ...
    (comp.object)
  • Re: Object Oriented Concurrency
    ... Please explain what techniques a DBMS ... The concurrency issues and solutions are exactly the same for object state variables in memory as they are for fields in a DBMS table. ... And that design can be implemented in Java, Basic, or Haskell with equal facility. ... Note that a DBMS engine is just another application; the only thing different is the problem space. ...
    (comp.object)
  • Re: Object Oriented Concurrency
    ... the relational model is orthogonal to concurrency features. ... since the only thing a DBMS do is to manage data. ... Couldn't agree more that a DBMS is useless if your applications ...
    (comp.object)
  • Re: Object Oriented Concurrency
    ... Large applications outside the CRUD/USER realm *use* data but they don't ... A DBMS manages the storage of data for generic access. ... would be responsible for the concurrency issues in its implementation, ...
    (comp.object)
  • Re: Object Oriented Concurrency
    ... Please explain what techniques a DBMS ... engine employs for concurrency that are not readily available to OO ... And like I said, the more DB features you add, the more it morphs into ...
    (comp.object)
Loading