|
|||||||||
| Home >> All >> org >> apache >> derbyTesting >> functionTests >> tests >> [ store overview ] | PREV CLASS NEXT CLASS | ||||||||
SUMMARY:  JAVADOC |  SOURCE |  DOWNLOAD | NESTED | FIELD | CONSTR | METHOD |
DETAIL: FIELD | CONSTR | METHOD | ||||||||
org.apache.derbyTesting.functionTests.tests.store
Class TestDurabilityProperty
java.lang.Objectorg.apache.derbyTesting.functionTests.tests.store.TestDurabilityProperty
- public class TestDurabilityProperty
- extends java.lang.Object
This program tests the system when the derby.system.durability property is
set to 'test'.
When the derby.system.durability is set to 'test', the system will not do
any sync to the
disk and the recovery system will not work property. It is provided for
performance reasons and should ideally only be used when there is no
requirement for the database to recover.
When set, the system will not do any syncs, the cases namely - no sync of the log file at each commit - no sync of the log file before data page is forced to disk - no sync of page allocation when file is grown - no sync of data writes during checkpoint
That means, when this property is set to 'test', - a commit no longer guarantees that the transaction's modification will survive a system crash or JVM termination - the database may not recover successfully upon restart - a near full disk at runtime may cause unexpected errors - database may be in an inconsistent state This program tests for 1. setting the derby.system.durability=test is actually not doing the syncs by timing inserts 2. check if a warning message exists in derby.log 3. read log.ctrl file and check if the flag is set or not 4. check if the log.ctrl file flag is not overwritten for the case when database booted with derby.system.durability=test set, then shutdown and database booted without derby.system.durability=test
- Version:
- 1.0
| Constructor Summary | |
TestDurabilityProperty()
|
|
| Method Summary | |
static long |
doInserts(java.sql.Connection conn,
boolean autoCommit)
Note doing inserts in autocommit mode is probably the worst case scenario in terms of performance as each commit will involve a flush/sync to disk but in case of the derby.system.durability=test mode, the syncs dont happen. |
static boolean |
isMessageInDerbyLog(java.lang.String derbyHome)
When derby.system.durability is set, a warning message is written out to derby.log indicating that the property is set and that it does not guarantee recoverability This test tests if a message is written out to derby.log or not |
static void |
main(java.lang.String[] args)
|
static void |
markerInControlFile(java.lang.String derbyHome)
if database is booted with derby.system.durability=test, a marker is written out into log control file to recognize that the database was previously booted in this mode Test if the marker byte is set correctly or not. |
static void |
markerNotOverwritten(java.lang.String derbyHome)
Test for case when database is booted without derby.system.durability=test but previously has been booted with the derby.system.durability=test. |
static void |
report(java.lang.String msg)
print message |
static void |
testNoSyncs(java.lang.String[] args)
Test if derby.system.durability=test property is broken or not. |
static long |
timeTakenToInsert(java.lang.String mode,
boolean create,
boolean autoCommit)
time inserts |
| Methods inherited from class java.lang.Object |
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
| Constructor Detail |
TestDurabilityProperty
public TestDurabilityProperty()
| Method Detail |
main
public static void main(java.lang.String[] args)
timeTakenToInsert
public static long timeTakenToInsert(java.lang.String mode, boolean create, boolean autoCommit) throws java.lang.Exception
- time inserts
doInserts
public static long doInserts(java.sql.Connection conn, boolean autoCommit) throws java.lang.Exception
- Note doing inserts in autocommit mode is probably the worst case scenario
in terms of performance as each commit will involve a flush/sync to disk
but in case of the derby.system.durability=test mode, the syncs dont
happen.
isMessageInDerbyLog
public static boolean isMessageInDerbyLog(java.lang.String derbyHome) throws java.lang.Exception
- When derby.system.durability is set, a warning message is written out to
derby.log indicating that the property is set and that it does not
guarantee recoverability This test tests if a message is written out to
derby.log or not
markerInControlFile
public static void markerInControlFile(java.lang.String derbyHome) throws java.lang.Exception
- if database is booted with derby.system.durability=test,
a marker is written out into log control
file to recognize that the database was previously booted in this mode
Test if the marker byte is set correctly or not. See comments in
org.apache.derby.impl.store.log.LogToFile for IS_DURABILITY_TESTMODE_NO_SYNC_FLAG
markerNotOverwritten
public static void markerNotOverwritten(java.lang.String derbyHome) throws java.lang.Exception
- Test for case when database is booted without derby.system.durability=test
but previously has been booted with the derby.system.durability=test. In
this scenario,the log control file should still have the marker to say
that this mode was set previously, and derby.log must also have a warning
message
report
public static void report(java.lang.String msg)
- print message
testNoSyncs
public static void testNoSyncs(java.lang.String[] args) throws java.lang.Exception
- Test if derby.system.durability=test property is broken or not. We time
inserts for 500 repeated inserts and make some approximate estimations on
how fast it should be. Since it is a timing based test, there might be
cases of a really really slow machine in some weird cases where this test
may have diffs in this part of the test.
So basically to determine if something is wrong, the following is done
to try best to eliminate issues with slow machines
1)if inserts with autocommit on is fast enough (an estimated
bound)
2)if not, then since no syncs happen , check if time taken to do
inserts for autocommit on and off are in proximity range
3)if 1 and 2 is not satisfied, then check time taken without this mode set
and with this mode set.
If they are in proximity range something could be wrong. It
might be good to check the machine configuration and environment when
test was running
Also note, although it would seem like a solution would be to bump the estimated bound to a high limit, this might not help since on a really good disk the inserts doing syncs might well be done within the bound and thus would not be possible to know if this mode was possibly broken.
|
|||||||||
| Home >> All >> org >> apache >> derbyTesting >> functionTests >> tests >> [ store overview ] | PREV CLASS NEXT CLASS | ||||||||
|
SUMMARY: JAVADOC | SOURCE | DOWNLOAD | NESTED | FIELD | CONSTR | METHOD |
DETAIL: FIELD | CONSTR | METHOD | ||||||||