Eamonn O'Connell

That could really be anything. Have a look at your persistContractorRecord() method. See what is causing NPE and take it from there. It could be that your design is not suitable for concurrent threads...

Good job Mark. Congrats!

Hi All,

I've read many of the threading related (ahem) threads, which have really helped me consider angles I had previously overlooked. One such angle I'm mulling over is the relationship between the locking strategy (as defined in the provided interface) and the requirement that the application be thread safe. Are they the same, or just similar?

My own view on this is that they only similar. The locking methods in the provided interface are offered almost out of convienence to the caller. The other methods (create, update, find, etc.) should be thread safe with out the help of lock, unlock, and isLocked. The locking methods are there to ensure that the following situation does not occur:

2 clients and 1 db/server
Both clients wish to book the same unbooked record
They both execute the booking almost at the same time.
The locking methods ensure that no double booking occurs.

I think this ties in with the argument about whether to expose the locking fuctionality to the client. Of course there is no right answer, but I think the locking functionality/responsibility should be propagated up to the client rather than say employing the adapter pattern at the db level.

Anyone hava any thoughts on this?

I find TestNG to be very handy for multi-threaded testing

see homepage for more

From the spec of the SCJD:
The Java platform used "must not have been superseded by a anew production version for more than 18 months by the time you make your submission".

I don't think any changes are wise, even extending the interface.

A method returning a List of type Contractor is at a higher level of abstraction than the Sun provided interface.

AFAIK, in order to execute readall/findall, the find(String[]) should return all results if all elements of the array passed in are null;

Thanks for the advice. I was reluctant to att the create functionality would add a whole new aspect to mt design: user input validation.

Create is defined in the provide db interface though...

Hello all,

I'm having trouble deciding whether it necessary to implement obvious functionality not made explicit in the spec.

For example, my project is the B&S Contractor Manager program. It is explicit in its requirement for users to book a contractor for a particular customer. It is not so, with the requirement for users to be able to create new contractors.

OF course users need to be able to create new contractors right? But where does the implementation of implied requirments end? If this judgement call another aspect of the scjd?

Cheers,

Eamonn.

Cheers for the advice. Documenting it sounds like the way to go...

Hey Folks,

This could be my first post here, but I've read many. Very Helpful!

On to the question...

Does any one know, or can anyone guess what the DuplicateKeyException thrown by the create method of the supplied interface is all about?

I just use the position of the record in the file as the key. Are we to use something else? Like the name as the key?

It seems like the consensus on this, is that while not required, verifying the magic cookie value is good practice. If this is the case then (here comes the stupid question) how if this verification done?

Do you find out and make a note of what that magic cookie value is, then when the data object (or whatever) attempts to open the file, you make sure it has this same (hardcoded) cookie value?

What if another application also used the database file, and made changes to this magic cookie value?

Hope this makes some kind of sense...