Jeff Philp

You must implement this interface as it says. If you fail to do any "must" requirement you can be automatically failed.

Indeed you are correct, perhaps I should clarify. I submitted my assignment, and then after successfully submitted it I scheduled the exam part of the certification.

So I finally submitted by assignment yesterday , firstly thank you to everyone who contributes to this board. Though I didn't directly ask more than a couple of questions, the experience shows through in the answers to existing threads and the ongoing answering of questions. We are all lucky for having such a friendly and knowledgeable place to discuss issues related to this certification.

As part of submitting my assignment yesterday I had to book for the exam part of this certification, and I noticed how full all the booking centres were. Now I am not claiming they are all like that, and hey it might just be here in NZ that it's full. But I would advise though who are planning on submitting before the 1st of Oct to do so urgently because finding a testing centre might be hard with such short notice.

There is a single jar file which needs to contain both the client and server code. As jar files can only have a single point of entry you need a single main method which can interpret the command line argument and launch the appropriate application.

At the command line you would be typing

java -jar runme.jar alone For standalone mode
java -jar runme.jar For network client mode
java -jar runme.jar server For the server

Maybe a fictional scenario is a good way of explaining this:

Situation 1:
There is only one computer in the office which has the database on it, the user is also using that machine.
In this situation the user would type java -jar [] alone
and specify on a configuration screen the required settings for accessing the database on the local machine

Situation 2:
There are many computers in the office, and 1 server which has the database on it.

On the server you would type:
java -jar [] server
and specify on a configuration screen the required settings

All the users would type
java -jar [] (no argument)
and specify on a configuration screen the required settings

Hopefully I have not confused you more.

There are three modes as described in your instructions for running the application:

"alone" - Stand alone mode where the client connects directly to the database

"server" - Starts up a Network server which accepts connections from network clients

"" (no argument) - Starts up a network client which talks to a network server for database requests.

So that is essentially three different configuration screens you have. So in network mode the client needs to parameters required to talk to the server, and the server needs to parameters allowing it to listen for connections, and the physical database it will be using.

There should be no hard coded database locations, or server addresses. (disclaimer: unless your instructions tell you to)

Its not deadlock I agree, I just didn't know if other OCMJD candidates worried about such a situation. Its more protecting a programmer using the API against themselves.

I think the hardest thing with this assignment is determining the right amount of functionality to include, walking that fine line between too little, or too much.

Sean Keane wrote:
Well your thread sparked my thinking Jeff. But people seem to consistently use the term deadlock on the forum when describing this scenario. So I was puzzled, because it doesn't seem like deadlock is possible to me, so maybe I was missing something .

Sean you are right, the more I think about it its not deadlock. Because technically (in the simple example I proposed) client A is stuck on itself, and it just means that client B is stuck waiting for the Client A to release the lock which will never happen. Client A isn't waiting on client B to release a lock.

I don't know how you would correctly describe this situation, but its a potentially bad one none the less.

Hi guys,

Thank you all for your replies, its much appreciated

I think I will just document the usage of the API in the Javadoc and explain why in my choices.txt as it will show that I have thought of a situation where if a client calls the same lock method twice with the same record number, and its using a single thread that it could get stuck there.

Roel, I am sure you are quite correct in this discussion being had before, and I am ashamed to admit how many pages of threads I have read on locking over the past few months. I probably just missed this discussion

I suppose you might be referring to the thread I started here

I think I was probably using the wrong terminology in calling it deadlock.

You could however get deadlock in the following situation:

Imagine a client whom is single threaded making the following calls:
Client A: lock(1)
Client A: lock(1)

And if the lock method doesn't allow the same client to lock the record then doesn't this potentially lead to deadlock? if for example a client B also wanted the lock for record 1, but Client A never returned from the second call to lock?

Hi Sean,

Thanks for your reply. Your right he does seem to be tracking the client and can cope with multiple requests for the same record. His code must be doing something similar to people whose projects do not include a lock cookie, and therefore have to have a way of identifying the client.

So there is at least one person in the same situation as me who has chosen to handle this situation, rather than just writing it into the API javadoc.

Hi All,

This is my first post, and firstly I just want to think Roel, Roberto, and Andrew for their consistently high caliber of replies. It has made working on this OCMJD project so much less daunting.

I am currently working on the Data class, and thinking about the the locking. I have tried searching through for the forums relating to multiple record locking etc., but I have not seen any topic cover the subject of a client trying to lock the same record multiple times.

e.g.
data.lock(5); // Thread 1 data.lock(5); // Thread 1 - if not handled Thread 1 will deadlock here waiting for the lock on a record it already has

Now for assignments which do not have a lock cookie its implied that the locking mechanism is aware of which client is locking the record, so it could easily detect multiple lock attempts on the same record and just return from the lock() method call. But my assignment has a lock cookie, which doesn't at first glimpse require me to track the client who locked the record as I can rely on them to pass the lock cookie when they are updating / deleting etc. If a single thread attempted calling lock on the same record multiple times, on locking code which was unaware of the calling client then it would deadlock waiting for the record to be released which would never happen.

My question is:
a) Should I handle this situation? Which would require my code to be aware of which client is attempting the lock.
b) and if I don't handle it, I can add this requirement to the Data Javadoc stating that the client must only lock one record at a time, and not make multiple attempts to lock the same record once the lock has been obtained?

I suppose if I should handle this situation, then the locking code needs to become aware of the locking cookie, and of which client is trying to get the lock.

Any thoughts would be much appreciated