Keith Jones

What do you mean by:

port number client uses

Is this the server's port the client wishes to connect to?

Hi all,

I kind of have an idea how to implement a socket solution but not an RMI one. I am looking into doing it the RMI way since I have read that that is the easier option as you don't have to implement a threadsafe server as that is done for you (although I have read that the dissadvantage is that you can't use the thread's hashcode as the magic cookie). What I'd like to know is in the case of sockets the settings I would save to the .properties file on the client side are the ip address and port number of the server. For RMI what counterparts to this would I need to save?

Thanks

Well my lock is on the map of locked records against thread hashcodes and the comdition is to check whether a record exists or is deleted in the database. The spec says that if a record is deleted or does not exist then we should throw a RecordNotFoundException. I put this code inside a synchronized block just to be on the safe side. It was an if statement but I have heard it should be a while statement so i changed it.

Well done Kasper. I doubt I'll even pass when I do finish and hand mine in.

Well done Kasper. I doubt I'll even pass when I do finish and hand mine in.

I have heard it said that one should never use an if condition in a synchronized block (and should replace it with a while) because if a thread slices out in the middle of executing the if condition then the condition that it was attempting to evaluate before being sliced out could be different when that thread slices back in because another thread could have changed it and this a problem because an if (unlike a while) continues execution from where it left off.

I have done this with my code and have found that it produces peculiar looking code. For example:

synchronized(lock) { while (someCondition) { throw new Exception(); } }

In this code will there be an endless stream of exceptions thrown? Are there cases when we can't just simply change 'if' to 'while'?

Cheers

I have heard it said that one should never use an if condition in a synchronized block (and should replace it with a while) because if a thread slices out in the middle of executing the if condition then the condition that it was attempting to evaluate before being sliced out could be different when that thread slices back in because another thread could have changed it and this a problem because an if (unlike a while) continues execution from where it left off.

I have done this with my code and have found that it produces peculiar looking code. For example:

synchronized(lock) { while (someCondition) { throw new Exception(); } }

In this code will there be an endless stream of exceptions thrown? Are there cases when we can't just simply change 'if' to 'while'?

Cheers

Surely that's not possible since the specifcation for the unlock method says that we must throw an exception if we try to unlock a deleted record.

According to the specification of the lock method this method

Locks a record so that it can only be updated or deleted by this client.

In the case of delete, does this mean that we do the following:

synchronized (map) { while (isLocked(recNo)) { try { map.wait(); } catch (InterruptedException e) { } } lock(recNo); // call method to actually do the deletion of the record unlock(recNo); }

Problem is if we lock, then delete then attempt to unlock then we should get a RecordNotFoundException in the unlock method as that is what the unlock method should return for a record that is marked as deleted. Anyone have any ideas as to how this should be written?

However Mark,

I think Rudolph has a point. If we were to be literal about it throwing an unreorted exception does equate ti IMPLEMENTING the method. On th other hand it does mean we are not implementing it according to the specification. It's something that ca be argued either way and I'm sure if you explain yourself in the choices file you should be ok. But don't take that as a guarantee from me anyone. What do I know?

On another topic of the methods in the interface we have to implement which of those methods use lock, unlock and islocked?

Does anyone have an answer to this question though?

I guess that is fair enough. I have already written the code for these methods so I might just leave them in. For those who have done this we could mention in our choices.txt files that we have written them so that if we add this functionality in the future into our GUI then the methods are already written. But definately your idea sounds better.

On another topic of the methods in the interface we have to implement which of those methods use lock, unlock and islocked?

Hi All,

Would I be right in saying that although we are required to implement the two interface methods 'create' and 'delete' that we are not actually required to use these methods via our interface?

What I don't understand is how to write the lock, unlock and islocked methods and why they are needed. Also, I don't understand what will get mapped against the record number in the locking code. I have heard talk of cookies and Monkhouse's book just has me confused even more. Anyone have any examples?

Thank you Mohammed