robert young
Posts: 361
Nickname: funbunny
Registered: Sep, 2003
|
|
Re: Felipe Gaucho on Optimistic JPA Locking
|
Posted: Aug 12, 2009 8:22 AM
|
|
> > A bug isolated to one place: the database code (either > > declaratively in the schema or [shudder] by triggers or > > [smaller shudder] stored procs. By allowing > application > > coders to make it up as they go along, one invites > > failure. It's a matter separation of concerns. The > > database maintains the data, the coder makes it look > > pretty. > > I'm not saying to make it up as you go along. There is > one specific approach that is guaranteed to work. I'm > getting the idea that you don't know what that is.
snarky. cool. I await enlightenment.
> > > A better solution > > > is to not let multiple applications update the > database > > > and channel the transactions through a single owner. > > > > That single owner is the database engine or TPM; which > is > > precisely what I've been saying. > > The problem is that it can't do it successfully. SQL > allows for improper updates.
not a true statement. if you've been smart: i) designed to 3NF or higher (about the key, the whole key, and nothing but the key) and ii) update only non-key columns (don't do row rewrites; java folk tend to do that a lot), then the database remains consistent with the real world.
> > > But in only one place. Not with lots of disparate > > application coders each making his/her won unique brand > of > > error. Don't assign to the technology the errors of > its > > implementers. A single point of failure, yes. That is > a > > GOOD thing, not a bad one. DRY applies to failure, too. > > And the issues you are concerned with appear when more > than one application can access the database. Making the > database the single point of entry is the problem, not the > solution. Saying that the DB is the single point of entry > is like saying the Pacific Ocean is the single point of > entry to Hawaii.
you don't get databases. they exist to control the concurrency of the data. period. in previous lives, TPMs controlled the concurrency (CICS). in still previous lives application did it. if you want to return to a 1960s paradigm, you're in for a world of hurt. I've seen a lot of that since 2000.
> > > The only assist from the application is to format the > data > > on the screen, and send back input. Anything more, and > > one has the Tower of Babel. Edits can, and are as we > > speak, be derived from the catalog and provided to the > > application code (generated, in fact). > > Exactly. The database doesn't (and can't) know that the > data the application is providing is handled properly. > That the code is generated is irrelevant. If your > r generator is broken your application will fail.
Yes it does. the rules for data consistency are in the catalog. that's the whole point. the database cares not a whit where the data came from. if the update meets the requirements, it gets done. if not, then not. > > > > What exactly is your solution anyway? Do you have > any > > > concept of have devastatingly bad your solution would > > > perform in a real web service? > > > > Works quite well, actually. The client side code looks > no > > different from what it would be if hand coded. > > What does hand coding have to do with anything? I've said > nothing about whether the code is hand-written or not and > it's completely irrelevant. You can generate stateless > web apps too.
what it has to do with is DRY: the rules for data consistency are recorded in one place, in the catalog, and all other tiers, either at source generation time or runtime, abide by those rules. very simple.
> > What exactly is the solution you are advocating anyway? > > > Doing what: writing siloed applications, or simulating > a > > TPM in your application code? The latter is what COBOL > > programs did in 1970. I know. I was there, and I've > had > > the pain of working on code (not the same applications) > > from that era still. Mountains of redundant code. > > I work with COBOL programs too and what I am talking about > is not similar in any way. It's an SQL based solution.
so far, what you've described (which you haven't much, except to complain that relational databases are ambiguously incompetent) is to put concurrency control in application code. like it or not, that's the Olde Way (doesn't matter what language is used, I just like COBOL examples because it makes the antiquity clear). been there, done that.
|
|