I've got to the point where I'm just about ready to finish tidying up my assignment, writing the userguide/choices documents and packaging it all up (and yes, it's been a long road!).
But, before I do all that I want to make sure my locking logic is fool proof - I see lots of people getting 80/80 for their locking mechanisms so I think it's doable.
So, my question is - what tests should I be writing to 'stress' my server/locking logic to ensure I am 100% confident it will pass Sun's tests?
I figure that when Sun receive the assignment they must hook your submitted implementation of DBAccess up to a test harness that just thrashes it to ensure your code stands up to their tests. What things do I need to think about when writing a similar harness of my own?
Yeah I saw that post although I'd kinda like to write my own test for a couple of reasons...
i. I'm paranoid. We all have subtly different assignments so I don't want to be testing my DBAccess implementation against a test class written to stress a difference class.
ii. I want to be 100% confident in my solution, and I wont be happy unless I fully understand what needs to be tested and how I can do that.
So, back to my original question - what kinds of things should I be looking for?
I can write a class the creates a load of threads that all try and lock the same record, or do random things like the test class posted in the above link. But my issue with this is firstly I don't really know what I'm looking for and secondly, this seems like a scatter gun approach.
For example, just thrashing it with a load of threads to see what happens doesn't seem very 'scientific'. I would have thought there'd be a better approach to testing the Data access class rather than battering it with threads and keeping your fingers crossed that some deadlock or corruption of the data occurs.
Originally posted by Chris Bicnal: For example, just thrashing it with a load of threads to see what happens doesn't seem very 'scientific'. I would have thought there'd be a better approach to testing the Data access class rather than battering it with threads and keeping your fingers crossed that some deadlock or corruption of the data occurs.
So you are thinking of boundary testing as a specific part of your testing strategy perhaps?
Yeah I guess it is Boundary Testing of sorts, although it's tricky because the GUI (and interface exposed from the server) doesn't utilise all the methods in the DBAccess interface provided by Sun.
This means I have to test the DBAccess implementation class directly which takes me back to my original point. I can write a class that creates a load of threads that all try and reserve, un-reserve and search at the same time but I don't really know what I'm looking for and how this proves that my implementation is thread safe.
i am currently finishing the B&S assignment, so maybe i can give you some advices on how to test the DB implementation based on my experience (although i didn't submit my assigment yet, meaning i could be wrong in my approach). Anyway, here is how i tested my own DB implementation :
1) first, use java.util.Logger intensively in the database implementation. It is part of the J2SE core classes and can be disabled at runtime, so this is in the scope of the assignement. This allow you to check exactly what the database code has done. Then performs several simple case ( several threads updating the same record for example, find on all the database), and check the results.
2) use JUnit to automate the test process. Here, i would advise to use the Callable interface to launch client threads (and not Runnable), because it's easier this way to get the Exception occuring in the client thread code. Here, you can check that every client thread has finishing its job (detecting some possible deadlock), that the database supports the load and that concurrent accesses create not data corruption or lost.
2) use JCarder on all the test you made in 2): http://www.jcarder.org/. This is an open source dynamic deadlock finder. According to the tests i have made, it can find possible deadlock even if it doesn't occurs, which makes it very powerful. You just need to run the instrumented code on the use case involved. Note that this tool has limitations (mainly, don't work on java.util.concurrent classes).
I hope this helps,
SCJP 1.5<br />SCJD 1.6<br />SCBCD in progress...
Joined: Aug 17, 2005
Thanks for the information, that's useful.
I've started to look at the logging although I'm not sure how best to configure this.
For example, do you let the user control the file name (and location), number of files to split the logs across, size of each file etc... by some means?
Do you have logging throughout your whole application, or just in the data layer?
How do you handle the logging with the application running in network mode on the same machine, do you not get any clashes?
Joined: Feb 17, 2007
the interrest of logging is to be able to select at runtime some part of your software, and get information from this part at a given level of detail. To do so, you have to :
1) use Logger static instance in each class where you want information, giving to the Logger the name of the class. (for example, using this syntax in a ClassName class : private static final Logger LOGGER = Logger.getLogger(ClassName.class.getCanonicalName());
2) use logging level accurately (see the javadoc on how use the various logging level, from finest to severe).
3) use a logging configuration file. This point answer to your question about who control the logging. This is not intended to the end user, but more for the developper, and you specify it as a java property on the java command line : -Djava.util.logging.config.file=logging.properties To see an example of logging config file (this is in fact the default one), see in your JRE directory the file : lib/logging.properties.
Using these three steps, you will be able in your development work to select, let's say the database part only at a maximum level, putting the rest of the application and the J2SE core classes to the info level, updating the default file with :
java.util.logging.ConsoleHandler.level = FINEST and .level = INFO yourtoppackage.db = FINEST
About your two other questions : * i used the loggers mainly in the db code, but also in the GUI part to log unexpected Exception, for example. * i used logging with only one application at a time, so it was impossible to encounter the case you mentionned. However, i think there is no problem if you use the FileHandler in the default lib/logging.properties configuration file (as the %u is meant to resolve conflict).
java command line : -Djava.util.logging.config.file=logging.properties
This is not allowed in the assingment. It states "Your programs must not require use of command line property specifications", or is this not the case for you.
Joined: Feb 17, 2007
The exact statement from my assignement is "Your programs must not require use of command line arguments other than the single mode flag, which must be supported", the single mode flag being "alone" or "server".
Using a command line property argument for logging doesn't conflict with this requirement, because the application runs perfectly without logs (if your logs are well written, i.e doesn't change any state anywhere in the code).
It means the end user can use the application without knowing that this logging feature exists.
Joined: Jul 31, 2008
Your programs must not require use of command line arguments other than the single mode flag, which must be supported. Your programs must not require use of command line property specifications. All configuration must be done via a GUI, and must be persistent between runs of the program.
Allowing logging from command line would fail the configuration settings, but remember that the accessor would run the project from the command line; and i dont think the accessor would imply the settings for the logger.
Moreover logging settings can be implemented in server GUI; this is better design: just like most softwares you can enable logging and disable logging. [ August 20, 2008: Message edited by: Alenkhe David ]
Joined: Aug 17, 2005
I disagree, there's a difference between 'requiring' and 'supporting'.
Giles's solution doesn't require extra command line parameters, but it supports them. There's nothing in my specs saying you're not allowed to support extra optional command line parameters.
Secondly, this is functionality meant only for developers so I'm not so sure putting the logging option in the UI is a good design choice. Why would business users (i.e. the client you're developing the app for) care about logging? It's not like they could do anything if there was a problem!
I'm not after starting a riot here - just my two cents! :-)