On Mon, 21 Sep 2015 11:19:16 +0200 "R.Smith" <rsmith at rsweb.co.za> wrote:
> On 2015-09-21 01:53 AM, Nicolas J?ger wrote: > > hi, > > > > > > Scott Robison wrote: > > > >> 3. Some time passes and some external process may alter the schema. > >> > > is it really possible ? if the answer is yes (I thought when a > > process open a communication with the DB, other processes can't > > alter the DB), for me that would mean that the design(s) of the > > program(s) wich communicates with the DB is bad. > > This is the entire point of a database - allowing multiple things to > see the data. A system which only allows one thread to read data is > just a file-handler. Let's understand plainly: It is an isolation failure. All the rows from a SELECT statement are the product of an atomic action. The schema can't change *during* an atomic action. Of course, isolation is an illusion, and other DBMSs take different approaches to it. They either disallow schema changes to tables against which read locks are held, or they snapshot the results and apply the change, or they queue the change as a pending write until the read lock is released. I don't know of another, though, that just throws in the towel. Not to be snarky about it, but depending on what you mean by "file-handler", I can think of a few systems, such as stdio, that provide access by more than one thread to a single file. They don't provide much sense of isolation, though, except in append-mode. --jkl
