John McParland wrote:Hi,
the exam went quite well thanks. There were four questions, each of which asked me something about which I'd already invested significant time and effort into during the design and implementation of the assignment. I would say the exam is straightforward but not easy. I feel it is best to have prepared for it, such as re-reading your choices.txt and taking on some practice questions were a great help to me.
Now just to badger Oracle to allow me to upload my assignment.
Robin van Riel wrote: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 ;)
Roel De Nijs wrote:First of all, I changed your post a bit and removed the implementation of the bookAccomodation method. We prefer pseudo-code when complete methods are posted, because we try to prevent providing complete solution/logic (otherwise someone else can just copy/paste everything he/she needs to complete the assignment).
Let's start with the easy one. My main reason to implement record cache was: I don't have to handle the IOException in each CRUD-method. Another reason is that if 2-3 people say: "hey, I implement(ed) the record cache and that was so easy", it might influence people which are just starting their assignment. Because if they use this strategy, they will find more people to help them if they have an issue. In the Sun(ny) days (before Oracle acquisition) this certification was a lot more popular, so you had 5-10 people which were working on the assignment simultaneously, so much more traffic/questions in this forum. Nowadays it's just 1 or (if you are lucky) 2, sometimes even none for a couple of weeks. So people (have to) make more decisions on their own.
In order to answer the server side question, I need to know which methods do you expose to the client? The methods from the given interface? Or business methods like bookAccommodation and findAccommodations? If you expose business methods you'll have a thin client, otherwise it's a thick client. In a thin client starvation will never happen, because the server code always completes (unless a developer makes a mistake and forgets to unlock record for example).
Roel De Nijs wrote:First of all in the createRMIServer method I would expect a return of server instead of the creation of another object. Secondly lock and unlock should only be used for updating/deleting a record, not for reading one.
Roel De Nijs wrote:On the starvation subject. Based on the RMI server factory pattern I assume you opted for a thick client. One of the drawbacks of this approach is when a client which owns a lock crashes for some reason this record will be locked forever and can never be locked by another thread/client. This is a drawback you should definitely consider (as you do at this moment ). But it's not always necessary to handle this in the code, you have a choices.txt (the decision document) where you can list this as one of the drawbacks and give some possible solutions to this problem. And that will be fine, you don't have to implement any of them. Just considering and showing that you put a lot of thinking into your design is enough.
Similarly I implemented a solution with a record cache (so reading file in memory). Of course with a very big file I can ran into memory issues. So I mentioned this in choices.txt and provide some alternatives to solve this issue (e.g. ignoring the records in the past). I didn't implement any of these alternatives (just my simple record cache) and passed with a perfect score.
(I moved your posts in a new thread, they deserve a thread of their own )
Glen Iris wrote:
Joel Mata wrote:
Hi Glen, not much to add, just an confirmation that i did receive the same answer from Oracle. I did the Java SE7 fundamentals, it seamed to be the cheapest option.
Did you get much / learn much from the course?
Roel De Nijs wrote:In my application design I just have 1 Data instance (which is responsible for both locking and file manipulatons). If you have by design multiple server instances you'll need to share some information. Otherwise you won't have a multi-threaded application and you'll definitely fail for violating a must requirement.
Marking the locking manager as static is one of the possible scenarios.
Glen Iris wrote:I got some clarification from Oracle on this today:
Thank you very much for your email.
Each course you take will be recognized for one certification only.
For example, if you take the UML course and complete the course submission form asking Oracle to attach this training to the OCJMD certification, you will have to do an additional one from the list of approved trainings for the OCMJEA.
Please let me know, should you have any additional questions.
I guess thats a no then
Roel De Nijs wrote:And one other important note: due to the mandatory course requirement this certification is significantly more expensive than the other certifications (like OCPJP7, OCPJWSD,...)
Roel De Nijs wrote:With a RMI factory I would expect something like:
Roel De Nijs wrote:How can a file be opened on the client if this fily is physically residing on the server
Roel De Nijs wrote:
Joel Mata wrote:is this acceptable?
Of course! That's what RMI is all about.
And if you think about it? If the database is shared among the clients, what would happen with the database file? This file only exists server side...
Rehan Zahoor wrote:The RMI creates a skeleton and a stub. RMIImpl would be on the server the client would just have a shadow of it. So factory pattern works alright.