Re: Object Oriented Concurrency

On 15 Apr, 21:59, "H. S. Lahman" <h.lah...@xxxxxxxxxxx> wrote:
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.

Obviously concurrency features in a DBMS only have value when managing
data, since the only thing a DBMS do is to manage data. But your claim
"concurrency has nothing to do with DBMS features", is still invalid.

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.

In other words, two-phase commit is not unique to the RDB problem
space. Two-phase commit may be useful in all problem spaces with
multiple users accessing data. Or does the word "stored" has an
significant meaning here? Are there un-stored data too? Are there a
significant difference if data is stored in RAM, disk, flash-memory or
whatever?

If that is not the problem you are solving, then it is pretty useless.
Yes, if you are working in a single-user environment or not accessing
data, it is pretty useless.

//frebe
.

Relevant Pages

  • Re: Object Oriented Concurrency
    ... the relational model is orthogonal to concurrency features. ... happens to be tailored expressly to the RAD CRUD/USER realm. ... since the only thing a DBMS do is to manage data. ...
    (comp.object)
  • Re: Object Oriented Concurrency
    ... the relational model is orthogonal to concurrency features. ... happens to be tailored expressly to the RAD CRUD/USER realm. ... since the only thing a DBMS do is to manage data. ...
    (comp.object)
  • 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)
Loading