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.
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 )
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).