Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Concurrency in an RDB

Re: Concurrency in an RDB

From: David <davidbl_at_iinet.net.au>
Date: 19 Dec 2006 16:25:53 -0800
Message-ID: <1166574353.111425.137600@f1g2000cwa.googlegroups.com>

NENASHI, Tegiri wrote:
> "David" <davidbl_at_iinet.net.au> wrote in
> news:1166530519.065982.45910_at_a3g2000cwd.googlegroups.com:
>
> >
> > NENASHI, Tegiri wrote:
> >> "David" <davidbl_at_iinet.net.au> wrote in
> >> news:1166489213.076542.73990_at_79g2000cws.googlegroups.com:
> >>
> >> > NENASHI, Tegiri wrote:
> >> >> "David" <davidbl_at_iinet.net.au> wrote in
> >> >> news:1166446464.885673.257380_at_f1g2000cwa.googlegroups.com:
> >> >>
> >> > [snip]
> >> >
> >> >> > Consider that 50% of the individual transactions break the
> >> >> > constraint. Then batching won't help. Eg try a batch of size 2.
> >> >> > Expectation value of number of compiles per batch = 0.25*1 +
> >> >> > 0.25*2 + 0.5*3 = 2.25, which is actually worse than not batching
> >> >> > at all.
> >> >> >
> >> >>
> >> >> How it is possible that the expectation is 2.25 ? It is 0.25*1 +
> >> >> 0.25*1 + 0.25*2 = 1 -- one is incorrect two times and two are
> >> >> incorect one time. It is the same like with individual arrival
> >> >> and it is not surprising because the model of probability is the
> >> >> same.
> >> >
> >> > My reasoning was as follows... The batch consists of two
> >> > transactions T1,T2.
> >> >
> >> > If both transactions are valid then only one compile is needed (to
> >> > check the entire batch) but this only occurs 25% of the time.
> >>
> >> Very well. But I do not understand what it means to compile the
> >> entire batch. If the batch has two transactions one needs two
> >> compiles, or may be three compiles two for each transaction and one
> >> for the batch why only one compile ?
> >
> > Apply T1 then T2, then compile the end result. If we are lucky and
> > the compile succeeds, both transactions have been validated with only
> > one compile. This assumes two wrongs haven't made a right!
> >
> >> > Otherwise it is necessary to compile after applying only T1. If
> >> > this succeeds then we deduce that T2 is bad. This occurs 25% of
> >> > the time, and required two compiles.
> >>
> >> It is the same -- three or two compiles because it does not matter if
> >> the transaction is bad or it is good.
> >>
> >> >
> >> > Otherwise we have to compensate (or discard) T1. Since we have
> >> > already performed two compiles and we haven't done anything to
> >> > determine the correctness of T2, this case (which occurs 50% of the
> >> > time) requires 3 compiles.
> >>
> >> I do not understand. Perhaps you describe again what is the
> >> transaction compile and when it takes place and why you need the
> >> compiles for the entire batch plus compiles for the individual
> >> transactions.
> >>
> >> SO far I see from your words that the number of compiles does not
> >> depend of if transaction is bad or good because the compile is needed
> >> always, so the percent of bad transactions does not play a role.
> >
> > If compiling T1+T2 fails [#1],
>
>
> It is impossible to see what you mean because you have not responded to:
> what the compile of transaction is. Why compile(T1+T2) is diffrent of
> compile(T1), compile(T2) ? What is the compile ?

I brought up this example to show that complex integrity constraints can lead to poor performance. There is a DB of source code with an integrity constraint that it must compile successfully at all times. This would normally require a recompile of the source code to validate every mutative transaction (a failure to compile would cause the transaction to abort). Sampo suggested that transactions could be validated in batches (ie accumulated) so the recompile was performed less often. I pointed out that if the error rate is high then batching won't help at all.

Cheers,
David Received on Tue Dec 19 2006 - 18:25:53 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US