Re: Object Oriented Concurrency

Responding to topmind...

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.

The only way data comes into play is determining where concurrent threads must be synchronized. The fact that the data is represented in a particular way is completely irrelevant. The concurrency issues and solutions are exactly the same for object state variables in memory as they are for fields in a DBMS table. IOW, an Activity Diagram in UML full of forks and joins is going to look exactly the same no matter how the data that the processes chew on is organized. 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. 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.

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. But the basic techniques to provide concurrency under the hood would be the same.

--
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
    ... 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)
  • Re: Object Oriented Concurrency
    ... (and would morph into a database if it did). ... Please explain what techniques a DBMS ... engine employs for concurrency that are not readily available to OO ... You are talking about the external manifestation of a specific concurrency design model used within the DBMS engine. ...
    (comp.object)
Loading