Path: news.cambrium.nl!textnews.cambrium.nl!feeder8.cambrium.nl!feed.tweaknews.nl!85.158.31.10.MISMATCH!newsfeed-0.progon.net!progon.net!newsfeed00.sul.t-online.de!t-online.de!border2.nntp.dca.giganews.com!nntp.giganews.com!backlog2.nntp.dca.giganews.com!nntp.pipex.net!news.pipex.net.POSTED!not-for-mail NNTP-Posting-Date: Wed, 17 Jun 2009 11:46:49 -0500 Newsgroups: comp.databases.theory From: Roy Hann Subject: Re: Question about SERIALIZE transaction isolation References: <330366c9-0c34-4826-a31e-896e466e0e0e@k2g2000yql.googlegroups.com> User-Agent: XPN/1.0.0 (Monkey Business ; Windows) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID: Date: Wed, 17 Jun 2009 11:46:49 -0500 Lines: 50 X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 82.133.118.245 X-Trace: sv3-Smn6y2ZqkIaJu43YXMHKbbqymutsNUdaDVuZY0jVXspSLHslNYznYH0ziVKVCarephohYjRJGSaSpjS!YBi65mMeddmznkcUfj1rVBzwoF/uI4iOn8SqCBh31avKS+pVF2oKi/K7KPBfGtiQ2/OlcByANGl8!UCUGuJ080pu5urudoX2w X-Complaints-To: abuse@dsl.pipex.net X-DMCA-Complaints-To: abuse@dsl.pipex.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.39 Xref: news.cambrium.nl Brian Selzer wrote: > > "Roy Hann" wrote in message > news:ef6dncCufqMTcqXXnZ2dnUVZ8k6dnZ2d@pipex.net... >> Christoph Rupp wrote: >> >>> Hi, >>> >>> i'm nearly ready for my first release of my new concurrent, multi- >>> threaded, ACID transactional, logical idempotent logging, lock-free >>> database engine (key/value storage). >>> >>> OK, enough buzzwords for today :) >>> >>> Some of you were kind enough to help me a couple of times with my >>> questions. This one is about the behaviour of a read-only transaction >>> in the SERIALIZE isolation level. >>> >>> TXN A: >>> BEGIN >>> INSERT (a, b) >>> >>> TXN B: >>> BEGIN >>> FIND (a) >>> >>> Does the lookup of an un-committed item return KEY_NOT_FOUND or does >>> it create a transaction conflict? >> >> The key shouldn't be found in transaction B, and to maintain >> serializable isolation it should never be found even by a future query >> in the same transaction. > > This is not what is intended by the serializable transaction isolation > level. A transaction executing under the serializable transaction isolation > level requires that every update by /other transactions/ be blocked if it > might affect query results. I think you misintepret what I meant by "same transaction". I meant "the same" transaction B. My apologies for permitting the misreading. > Updates that occur within a transaction > /should/ be seen by subsequent queries within the same transaction. Of course; but I didn't say otherwise. -- Roy