Robin van Riel

@Mikalai:

Ten days after taking my essay I got contacted by the OCP team, explaining me that I hard coded the path to the properties file .
I guess they could have failed me for that, but instead they requested an updated version using a relative path.

Approximately four weeks after resubmitting the assignment I received my grade.

Hi all,

I just heard I passed for my OCMJD exam (Bodgitt & Scarper) and I can't help but think I owe it for a large part to you guys.
Your many questions, thorough answers and huge patience were a big help to me.
Hopefully I'll be able to pay it forward.

Thanks again,
Robin.

Hi Roel,

No worries, I fooled myself long before I read your post ;).

The reason mentioned by Roel for creating an extended interface is of course a perfectly valid one, but please don't be fooled (like I was at first) by the notion that you need to extend it to add missing functionality.
I thought the original interface wouldn't suffice since I wanted records to be returned instead of indices, I wanted a book method to be in there, etc.
While in fact the original interface contained all the basic methods I needed for the Bodgitt & Scarper assignment.

I ended up making the search ("find" returning records) and book methods part of the service interface, instead of the data interface.
These methods couldn't care less where methods like "read" and "find" get their data from (RMI, Sockets, DB File, etc).

Since no required jar file name was mentioned in my version of the Bodgitt & Scarper assignment, I assumed it didn't matter much.
I called it "rvriel_bodgittandscarper.jar".

But then again, I'm not sure yet if I passed ;)

Thanks Roel,

This means I can get rid of some unnecessary compexity.

Still not finished, since documenting leads to refactoring .

I always presumed the Data class should be used as an entry point for accessing the DB file data both explicitly (reading/writing the DB file) and implicitly (RMI calls).
However, after rereading the instructions, I've come to doubt this, especially since some DBMain methods mention file operations (e.g.: "Reads a record from the file").
It would make my life slightly easier if I didn't have to use the Data class as an entry point for executing the RMI calls.

Any thoughts on this matter?

Thanks in advance!

Way to go Margarita!

I agree this forum is invaluable when working on the OCMJD assignment.
Will submit my solution this weekend (currently finishing up the documentation) and hope for the best ;)

Thanks for your fast reply Roel!

You were right, I was on the wrong path.
My main mistake was trying to implement the locking mechanism on a higher abstraction level, while I should have kept it as close to the file manipulation classes as possible.

I'm still doing something wrong (test class fails), but those remaining bugs will be squashed .

About this getting the locking mechanism to work flawlessly, I'm still in the process of tackling this.

I've synchronized the relevant methods within the Data class and am currently using the following construction for the read, update, book and delete methods:

while rec x is locked => wait
- try
-- lock rec x
-- perform action on rec x
- finally
-- unlock rec x
-- notifyAll

The test class I'm using seems to be happy, but since I hardly ever use locking during real life projects, I hope I didn't overlook anything.
Thanks in advance for any feedback!

Hi Peter,

Apart from finishing up my documentation the only thing I still need to do before handing in my assignment is making absolutely sure my locking mechanism is working as expected.
The more tests the merrier .

So if you would still be willing to share you're locking test, it would be very welcome.

Cheers,
Robin.

I see.
Thanks for clearing that up, Jelle!

Hi all,

While documenting my OCMJD code I noticed I'm using an empty interface combining the Remote interface defined in java and the SubcontractorService interface I wrote:
public interface RmiSubcontractorService extends Remote, SubcontractorService {}

This combined interface is used by my RmiServer class, which is used to register and unregister the SubcontractorService:
public class RmiServer extends UnicastRemoteObject implements RmiSubcontractorService {

This works just fine, but I wanted to see if the RmiServer class would still work as expected when implementing the combined interfaces directly:
public class RmiServer extends UnicastRemoteObject implements Remote, SubcontractorService {

I was surprised to find this broke the RMI functionality.
That is, the service can be registered, but my RMI client is suddenly unable to find it.

OO wise it doesn't make much sense to me.
Does anyone know if this is an RMI related issue?

Thanks in advance.

Hi Margarita,

Sad to hear it!
I hope you'll easily pass next time around.