Originally posted by William Smith II:
I submitted my assignment on Dec 26th and wrote the exam on Dec 28th. My exam is still in pending status. That's 7 weeks. I'm getting frustrated!!! I'm really frustrated because I think I've seen one other individual who submitted after me and got his results back in 2 or 3 weeks.
I've already sent two emails to the who2contact email address.
Sorry, I just needed to vent.
Originally posted by Alex Belisle Turcot:
Hi all,
I passed! I was hoping/aiming at a better score, but it's all behind me and it's all good
General Considerations (maximum = 100): 99
Documentation (maximum = 70): 70
O-O Design (maximum = 30): 30
GUI (maximum = 40): 31
Locking (maximum = 80): 44
Data store (maximum = 40): 40
Network server (maximum = 40): 40
Thanks all, and wish you the best!
Alex
Originally posted by R van Vliet:
Hi conny,
I was unable to extract a question from your post. Could you please be more specific as to what you are confused about?
Also, on a sidenote, it's much easier to read code if you use the appropriate code tag.
Originally posted by Alex Belisle Turcot:
Hi,
I'm not there yet.. in 2 or 3 weeks I believe..
This has been ask many times and there are few very good thread where people detail what they did...
I read some say it should not be much more than 1 page. Maybe 2-3 top.
Look it up yourself on the board, you'll find a lot of people shared their experience about their choices.txt
Regards,
Alex
[ November 20, 2007: Message edited by: Alex Belisle Turcot ]
Originally posted by R van Vliet:
Hi Andrew,
Thanks for your reply and I agree, although I think in the case of the 2nd instructions the safer bet is to let the code follow the instructions to the letter (avoiding the woes of assessors that got a speeding ticket that morning) and document your reservations in choices.txt.
You make a good point about RMI. Although perhaps even in the case of RMI tracking the thread would be a viable option. I wouldnt use the thread to uniquely identify a client to begin with, but it's still a way to avoid the deadlock situation mentioned. All you'd basically care about is one thread trying to lock record X twice. After that check you can always seperately check if you're talking to the same client and deal with the request to lock appropriately, still avoiding the deadlock in the process.
I almost feel a need to apologise for the fact that I too belong to that majority that objects calling lock/unlock from the client
Originally posted by R van Vliet:
By the way, for those that delegated locking to a seperate class (say LockManager), does anyone guard against things such as :
Since most operations requiring record lock are atomic and are guaranteed to unlock the record before returning this isn't an implementation problem, but looking solely at the scope of LockManager wouldnt it be better to disallow a thread locking the same record twice? I havent noticed anyone doing or discussing this, hence asking.
Originally posted by Musab Al-Rawi:
Alex's way is better but in order for you to do it you have to provide a higher layer which is the business layer.
The business layer provide the main functionalities from the client point of view, so the client won't have to invoke lock, update then unlock to do the booking operation, instead he will invoke book() which does the locking updating then unlocking.
Originally posted by Musab Al-Rawi:
Sorry for the late reply,
I am not sure if I got your question right or not.
What I understood from my assignment is isLocked() should return true if the record has been locked by the invoking thread, if this method returns false then you shouldn't allow the thread to do update/delete kind of operations.
Another thing to mention is that when you want to lock a record all what you need to do is call the lock() if the record is locked by another thread (user) then your thread should wait until the locking thread unlock() the record.
You don't have to lock on a specific record (as it may be more complicated to implement) UNLESS it is required , i.e say thread 1 is locking record 1 then thread 2 should be able to lock and change recrod 2 if it is not locked. an easier approach is: if thread 1 is locking record 1 then thread 2 can't lock record 2 until thread 1 unlocks record 1.
final thing to mention is always try to follow the following style when locking:
to make sure that the record is unlocked whether the operation fails or succeeds.
Originally posted by Musab Al-Rawi:
Hi Conny,
As an advice start with the Database first and forget about the GUI.
now in the DVD Example he is identifying the locker using an instance of the fasade (that's why he is sending "this" with the record number to the reservation manager instance).
You can use the same example in the DVD example. But make sure that your interface doesn't require you to return a magical number or cookie.
now you can improve on the design of the locking that you have in the book and most probably you have to make changes to suit your design and data.
hope that helped.
[ November 15, 2007: Message edited by: Musab Al-Rawi ]
Originally posted by Alex Belisle Turcot:
Hi,
I'm not quite sure what is your question, could you rephrase for me ?
Regards,
Alex