Hi, Is it okay to use factory pattern mention in Andrew book with cookie in assignment? I have design with both options with and without factory pattern in RMI but factory one runs in flying color under all test for locking where as non-factory pattern model for RMI finds some problem in some test case. Even if I use factory pattern for RMI I have always use cookie for lock-unlock-update-delete method. Do you guys think I might loose marks for network or OO design for using factory pattern where cookies are available for locking but threads are never use or hashcode for locking purpose??? Please comment.
// Locks a record so that it can only be updated or deleted by this client.
// Returned value is a cookie that must be used when the record is unlocked,
// updated, or deleted. If the specified record is already locked by a different
// client, the current thread gives up the CPU and consumes no CPU cycles until
// the record is unlocked.
public long lock(int recNo) throws RecordNotFoundException;
Thank you, Ken [ May 26, 2007: Message edited by: Ken Boyd ]
I'm exactly at the same stage in my assignment, and was, just like you, doubting about this. I think my ideas are going in the direction of not using the factory, as the assingment tells you to keep things as simple as possible, and it looks a bit like overkill to me.
However, enough people seem to be using it, and if your version with the pattern is working better than the one without, I wouldn't give it more time, and just use the one with the pattern.
Thank you guys as I was stuck with this issue for sometime. I will go with factory pattern as you can use it for future enhancement for crash client detection and returning multiple objects instead of DB only at this time. At the same time it cost you in performance a little bit i.e. more threads and little hit on performance but that won't be big deal since it is pilot program.