Heri, "H. Steuer" schrieb: > > Hi Stefan, > > > Does the second shell actually perform those changes? In this case, I > assume > > it's got something to do with the isolation level / consistent read in > > InnoDB tables. "shell1" sees all its changes immediately, "shell2" (the > > application) has just a snapshot of the data at the time it performs the > > select. > > Well, in fact "shell2" is just another mysql shell I opened. So the > following is the situation : > > Application loops. "shell1" changes data. "shell2" (which is just another > mysql shell i opened) can see the changes. > The application still doesnt. > > So, how can that be caused by the isolation level ? Even after issuing a > COMMIT in "shell1" (the shell that changes data) > theres nothing visible in the application. > > > > > This should however only be true for the select the first time the > > application loops. But if it uses the same conn = mysql_init(NULL); (I am > > not a C programmer), it will keep the same isolation level, and thus, the > > same snapshot. > > Well, does that mean that I have to commit that "dummy" transaction in the > application just to have the commited data of > the other sessions available ? I call it "dummy" because this transaction
That's the point! The repeatable read isolation level requires that the data must be presented as they were when your own transaction (not just your SELECT) started! Therefore you should commit regularly (in your case on every loop iteration) even if you issue nothing but SELECTs. The good news is that in future releases of InnoDB/MySQL the isolation level "read committed" will become available. > doesnt change any data, just SELECTS it. > > Here I quote the innodb manual : > "If you are running with the default REPEATABLE READ isolation level, then > all consistent reads within the same transaction read the snapshot > established by the first such read in that transaction. You can get a > fresher snapshot for your queries by committing the current transaction and > after that issuing new queries" > > This would explain the behaviour of the application but seems quite useless > to me as I think the task of an atomic operation > should be to have changes done or completely rolled back. "should"/"should not": different isolation levels simply exist (dirty read, committed read, repeatable read)! Don't mix them up with what transactions do! Isolation levels deal more with __when__ I can see somebody else's permanent changes (committed transcations). > > Or do I get something wrong ? > > Thanks, > Heri > > --------------------------------------------------------------------- > Before posting, please check: > http://www.mysql.com/manual.php (the manual) > http://lists.mysql.com/ (the list archive) > > To request this thread, e-mail <[EMAIL PROTECTED]> > To unsubscribe, e-mail <[EMAIL PROTECTED]> > Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php Regards, Frank. -- Dr. Frank Ullrich, Netzwerkadministration Heise Zeitschriften Verlag GmbH & Co KG, Helstorfer Str. 7, D-30625 Hannover E-Mail: [EMAIL PROTECTED] Phone: +49 511 5352 587; FAX: +49 511 5352 538 --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
