Re: Phantom Inserts

In article <3jg60n$lmr@gatekeeper.cognos.com>, nigelc@Cognos.COM (Nigel Campbell) writes... . . . >Interbase provides phantom protection by default without requiring >readers to block writers or vice versa. Rather than use locking >on tables or indexes etc InterBase uses row versioning. Your >transaction can only see those rows whose transaction id is known >to be committed. >-- >Nigel Campbell Voice: (613) 738-1338 ext 3016 P.O. Box 9707 >Desktop Division FAX: (613) 738-0002 3755 Riverside Dr. >Cognos Incorporated MCI: nigel campbell || 3074729 Ottawa, Ontario >UUnet: nigelc@cognos.COM CANADA K1G 3Z4 Interbase has roots back with Digitals Rdb/ELN product....and uses a multi-versioning scheme. But isn't there a 'twist to it". Phantom protection means [in a simple form]: +++++++++++++++++++++++++++++++++++ User1 User 2 start trans select all foo where bar = '1' [5 found] start trans insert into foo (bar = '1') commitselect all foo where bar = '1' [6 found] commit -------------------------------- Can not happen!!!! Ok, there are two ways of preventing this. We have discussed one that the insert will be blocked....and there are two general methods of doing this, lock the table foo or if there is an index lock the index structure having to do with the value '1' so that no additional tuples can be inserted satisfying the selection criteria. The second method, which *may* be used is that you produce an *error* on the second select. Isn't the transaction model something like this for Interbase?? [not sure]. Curious, -Jay Feenan ********************************************************************* *** Jay Feenan *** *** Oracle Rdb Engineering *** *** *** *** opinions expressed here are solely my own and not those of my *** *** employer. *** *** *** *********************************************************************