I'm wondering, whether the "nobody ...." comment in the following sql file
(which is called via "$>db2 -t -f sql") :

$>cat sql
-- BEGIN
delete from NEW
;
-- nobody should to read from NEW at this point
insert into NEW (select * from OLD)
;
--END

could be removed or if it is possible that somebody could read from table
NEW between the delete and insert statement.

"Toralf Förster" <toralf.foerster (AT) gmx (DOT) de> wrote

Auto-commit is on by default, so commit happens after every statement.

On 7/19/2010 7:57 PM, Mark A wrote:
default for all new databases. So there can be concurrent queries.
These concurrent queries will see the "deleted" rows until the delete is
committed.
They will not see any INSERTed rows until that is committed.

Cheers
Serge

--
Serge Rielau
SQL Architect DB2 for LUW
IBM Toronto Lab

Serge Rielau wrote:


so an sql file like this :
$> cat sql
delete ...
;
insert ....
;
commit
;

called with this command:
$>db2 +c -vt -f sql

guarantees that nobody will see an empty table, isn't it ?

--
MfG/Sincerely

Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3

On Jul 20, 1:19*am, Serge Rielau <srie... (AT) ca (DOT) ibm.com> wrote:
Hello Serge,

indeed this was a feature. Our developer told me that he has to
rewrite all procedure after upgrading to 9.7 and activate
CURRENTLY COMMITTED , to do a commit after each sql. Is this true?

But, it works as expected, we are very happy. Onother application has
no more lockwaits after we upgrade to 9.7

Best regards,
Joachim

On 7/20/2010 4:30 PM, Joachim Müller wrote:

Generically I can say that relying on locks to synchronize sessions on
queries does not work with CURRENTLY COMMITTED.
That is the reason why we don't force the new semantics.
We ever so gently nudge people instead. :-)


--
Serge Rielau
SQL Architect DB2 for LUW
IBM Toronto Lab