dynamobi-build
commented
12 years ago [author="jvs", created="Fri, 4 May 2007 18:08:00 -0500 (GMT-05:00)"]
Mail from Zelaine:
When looking at LER-5054, one of the things I noticed in the server log
file was that certain statements appeared to be prepared multiple times
in the log file even through they were only referenced once in the
script file. This is because SQL statements in the concurrent test
framework are first prepared and then subsequently executed. So, the
log shows two prepares, the first corresponding to a prepare with no
execute and the second corresponding to a prepare and execute.
Looking at this further today, it turns out that certain statements are
actually being executed at prepare time, namely ALTER TABLE, ALTER TABLE
REBUID, ANALYZE TABLE, and TRUNCATE TABLE. So, if you prepare and
execute them in JDBC, you end up running these statements twice!
The ALTERs and ANALYZE appear to always have been this way. It looks
like this is the way Stephan Zuercher implemented ALTER TABLE, and then
John Pham mimiced that with REBUILD and ANALYZE. With the snapshot
changes, to make TRUNCATE run concurrent with DML, I changed TRUNCATE
and ended up making it behave like those other statements.
The testcase in LER-5054 happens to do ALTER REBUILD and TRUNCATE and
the intermittent failure Sunny saw was related to a TRUNCATE. I don't
think the fact that the statements are run twice is a cause for the
failure, but maybe it throws off the timing of things.
Irregardless of that, we shouldn't be doing the redundant executes. Do
you think this is worth fixing? Or is it rare that these statements
will be prepared and executed vs just directly executed?
[reporter="jvs", created="Fri, 4 May 2007 18:07:14 -0500 (GMT-05:00)"] One outcome might be that they should be left as is (e.g. if the repository updates have to take place inside of validation), but the method names should be generalized to match reality. Another outcome might be that they should be resequenced.