The Artima Developer Community
Sponsored Link

Artima Developer Spotlight Forum
Felipe Gaucho on Optimistic JPA Locking

18 replies on 2 pages. Most recent reply: Aug 13, 2009 9:48 AM by James Watson

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 18 replies on 2 pages [ « | 1 2 ]
robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Felipe Gaucho on Optimistic JPA Locking Posted: Aug 11, 2009 9:52 AM
Reply to this message Reply
Advertisement
> > Once again: if you're wed to application code running
> the
> > data, you're back to COBOL/VSAM/1970. It doesn't
> matter
> > whether you've invented the euphemism "optimistic
> locking
> > in a stateless environment". You're still retrograde.
>
> It seems to me that you are stuck in the past (40 years
> ago to be precise.) The importance of statelessness is
> very basic and essential.

Those that seek do applications as they were done before Dr. Codd figured out the relational model, and other such as Gray, Reuter, Weikum, and Vossen figured out how to do transactions, are the ones stuck in 40 year old paradigms. Statelessness was the way of the 3270/360. Those that ignore (or don't know) history are doomed to repeat it.

>
> > As one of the earlier posts said: "All involved
> parties
> > must stick to the bargain and update the version column
> > (it's a 'collaborative protocol'). When one program
> (e.g.
> > because it doesn't use JPA) doesn't comply all others
> are
> > affected."
>
> You can ensure the version field is updated using database
> triggers. I thought you'd be a big fan of that.

Triggers, not so much.
>
> The argument that a solution is not reliable because you
> might make a mistake in implementing it properly is just
> rhetoric. It's a logical fallacy no more valid than
> saying seatbelts don't work because people can decide not
> to wear them. I could use your solution in my application
> and implement it improperly. Does that make your solution
> wrong?
>
> If an application accesses the database and doesn't update
> the table properly, then that's a bug.

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.

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.

>
> > Again, if you REALLY want your data correct, as the
> prime
> > directive of your application, the database (or TPM)
> MUST
> > control concurrency.
>
> Sorry, but that is just bullshit. A DBMS is software.
> It's not magical. I've had a to solve a number of
> f critical bugs created by people who believe that
> everything needs to happen in the database.

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.

>
> > The fact that many people are web
> > addled doesn't change the semantics of transactions.
> Read
> > Weikum and Vossen on transactions. What they say
> applies
> > universally, not just through SQL databases.
>
> The standard solution uses the features of the database.
> The point is that the database can't do it alone. The
> e application must assist.

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).
>
> 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.

>
> > The argument that stateless (with respect to the
> > datastore) behaviour can be implemented in anything
> other
> > than a siloed monolithic application (and even then,
> with
> > multiple coders and multiple subsystems, good luck) is
> > folly. Dr. Codd demolished that idea 40 years ago.
>
> I've been doing it for more many years. What you don't
> know is hurting you.

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.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Felipe Gaucho on Optimistic JPA Locking Posted: Aug 11, 2009 11:12 AM
Reply to this message Reply
> 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.

> 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.

> 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.

> 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 generator is broken your application will fail.

> > 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 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.

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Felipe Gaucho on Optimistic JPA Locking Posted: Aug 12, 2009 8:22 AM
Reply to this message Reply
> > 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.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Felipe Gaucho on Optimistic JPA Locking Posted: Aug 13, 2009 9:48 AM
Reply to this message Reply
> I await enlightenment.

When you update the row, you add the version to the where clause while simultaneously updating the version column. The alternate approach is to add all the column values to the where clause (which is the ALL option mentioned earlier.)

If your update results in 0 rows being updated, the row is either gone or has been updated by someone else since the data was read by that client. The DBMS eliminates the possibility of race conditions.

For this to work, the client must keep the version value on the row at the time of the initial read (or all column values) and use it in the update. It's possible to have completely safe stateless optimistic concurrency. Even if the client last read the row a week ago, it can update the row safely without any connection to the database or locking as long as no other client has modified it during that time.

> 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.

The things you are listing here are really basic stuff. The kind of things I would explain to a new hire out of school. What boggles my mind is that you think this guarantees correctness. What you are talking about here, while crucial, is just one part of ensuring correctness and consistency.

> 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.

That's the point. The database doesn't care if you execute an update based on a dirty read and overwrite fields with outdated values. Only the client can ensure that they don't do that. The more clients you have working directly on the database, the more change there is for error. It's possible that a DBMS could add support for version markers and enforce proper optimistic locking and I think that would be a great thing but I haven't seen any such feature in any DBMS that I've worked with.

Flat View: This topic has 18 replies on 2 pages [ « | 1  2 ]
Topic: Specs Without Tests Are Meaningless Previous Topic   Next Topic Topic: Skinning and Components in Flex 4's Spark Architecture

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use