Re: Ghost update in concurrent transaction

"Dan" <guntermann_at_verizon.com> wrote in message news:<tywYc.2364$bD5.1570_at_trnddc03>...
> "Sudin" <sudinkc_at_yahoo.com> wrote in message
> news:1dcfba52.0408291014.303025b_at_posting.google.com...
> > Hello can anyone explain what ghost update does in a concurrent
> > transaction? What I haven't understood is suppose an integrity
> > constraint exists which says x+y+z = 1000 and concurrent transaction
> > table below:
> > ========

 [snip]

>
> Hi Sudin,
>
> I am assuming that the original values (before T1 and T2) are such that
> x+y+z = 1000.
>
> Might I suggest that you create two serial schedules, each reflecting a
> serial execution of one transaction and then the other (T1->T2 and then
> T2->T1), with no interference of interleaving by the other transaction. If
> you work through these two scenarios, you will see that in either case, the
> integrity constraint is not violated by either transaction at commit time.
> In other words, the variable s would have a value of 1000 for T1 in either
> case, and x+y+z would still evaluate to 1000 for T2 in either case.
>
> The issue is not really the integrity constraint (in fact, the mode of

Word to word from the book it says "Transaction t1 observes only some of the effects of the transaction t2, and thus observes a state that does not satisfy the integrity constraints. This is called a ghost update.

So, t1 violates integrity constraint because it read a value of z that had value
z+100 which would in turn mean s = x + y + (z+100) instead of s = x + y + z?? Isn't it because of this that the value of s is 1100 ( mentioned in the text ) instead of 1000 and hence ghost update?

> integrity constraint as either deferred or immediate might have an effect on
> the effectiveness of the check), but the fact that the schedule involves the
> interleaving of operations of T1 and T2 and thefore allows for a condition
> where the two transactions interfere with one another and results in
> inconsistency. We can determine this because we can define a consistent
> transition of states by using a formal criterion based on what would happen
> if transactions were only allowed to occured in a serial fashion (T1 and
> then T2, or vice versa), totally isolated from one another. Since the
> result of the "Ghost Update" schedule does not produce a final state that is
> equivalent to a schedule that is serial across transactions, we can
> determine that the *isolation* of each transaction is circumspect. Since
> the effects of the interleaved schedule presented by the textbook are not
> equivalent to a serial schedule, the schedule is not considered to be
> *serializable*.
>
> The "Ghost Update" is really another term for the "Inconsistent Analysis"
> problem.
 

Nice, didn't know that. :)

> BTW, in SQL-92 parlance, this problem seems to imply that the isolation
> level defined across transactions is *Read Uncommited* because we can see
> that both a dirty read and a non-repeatable read are allowed.
>
> > cheers
> > Sudin.
>
> HTH,
>
> Dan G.

thanx for the promptness.
cheers
Sudin. Received on Mon Aug 30 2004 - 09:39:18 CEST