File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes B&S Locking Test Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "B&S Locking Test" Watch "B&S Locking Test" New topic
Author

B&S Locking Test

Chris Bicnal
Ranch Hand

Joined: Aug 17, 2005
Posts: 80
    
    1
Hi everyone,

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?

Thanks,

Chris
Jethro Borsje
Ranch Hand

Joined: Jul 22, 2008
Posts: 100
I am interested in writing such a stress test myself to. I am also working on B&S and I want to make sure my locking is working perfectly before I submit anything. I found some testing code in this thread: http://www.coderanch.com/t/188740/java-developer-SCJD/certification/Testing-Tool-Data-Class.


SCJP, SCJD
Chris Bicnal
Ranch Hand

Joined: Aug 17, 2005
Posts: 80
    
    1
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.

Any ideas anyone?

Chris
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11527
    
100

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?

Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Chris Bicnal
Ranch Hand

Joined: Aug 17, 2005
Posts: 80
    
    1
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.

Does that make sense?

Chris
Gilles Marceau
Ranch Hand

Joined: Feb 17, 2007
Posts: 78
Hello Chris,

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,

Gilles


SCJP 1.5<br />SCJD 1.6<br />SCBCD in progress...
Chris Bicnal
Ranch Hand

Joined: Aug 17, 2005
Posts: 80
    
    1
Hi Giles,

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?

Thanks,

Chris
Gilles Marceau
Ranch Hand

Joined: Feb 17, 2007
Posts: 78
Hi Chris,

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).

Hope this helps,

Gilles
Alenkhe David
Greenhorn

Joined: Jul 31, 2008
Posts: 20
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.


Jesus Regins..
Gilles Marceau
Ranch Hand

Joined: Feb 17, 2007
Posts: 78
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.
Alenkhe David
Greenhorn

Joined: Jul 31, 2008
Posts: 20
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 ]
Chris Bicnal
Ranch Hand

Joined: Aug 17, 2005
Posts: 80
    
    1
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! :-)

Chris
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: B&S Locking Test