I hope someone could give me some insight into my issue.
This has probably been discussed before, so I apologize in advance.
I have been trying to conform my project within the specification, however I am ofcourse nervous about the possibility of doing something which would be considered incorrect or auto-fail.
I would like to extend the oracle interface "DBMain" and provide some wrappers for the lock method, update etc inorder to use a locking cookie. For example:
This function would return a generated cookie which I could use in subsequent updates. My feeling is however that I will be punished for not calling their lock method explicitly. I would also like to do the same with
the update and unlock functions.
Do you think I would be penalized for doing this..... I dont think so... and I dont see why not... but I have to ask what you guys think..
Do you think I would be penalized for doing this..... I dont think so...
Yeah, me neither, champ. The thing is that you have to implement the interface provided by Oracle, and a lot of people choose to implement it as a facade. One question that you have to ask yourself: can this implementation (of the interface provided by Oracle) of yours be used in another application that uses this same interface and still provide the functionalities it is supposed to provide (lock, update, create...)? If so, then I'd say it's ok.
just try to leave that interface implementation as basic as possible. I am going to sleep on it...maybe I will come up with an idea tomorrow.
An alternative could be (and that's what I used to): generate an id on the client and use an extra method (e.g. setClientId) to set the client id before you make a call to lock. These calls must of course be an atomic operation. And that's also applicable for the other methods like update, delete and unlock
That is exactly the case, the method signatures do not support returning nor supplying a clientId to these methods, this is why I wanted to provide these new methods. I always find it simpler if you can provide the functionality to the caller, instead of making them perform multiple steps to achieve it.
Yes, the caller would have to synchronize the block when generating the clientId/lock etc...
But as of now I am leaning this way... only because I am somewhat nervous about messing with the interface, even though I think its the right thing to do. Anyway, its driving me crazy thats I am putting so much thought into this.... I'll just implement and be done with, leave the interface as close as possible and not affect the existing
Thanks for the reply, I appreciate your time..
Roel De Nijs wrote:If you decide to use RMI as networking protocol you don't have that guarantee and you need something like the clientId or some other alternative. But if you use sockets you don't need such an approach.
Yep, thats exactly the issue... I locked myself into doing RMI, and skip the sockets, simply because I have not done RMI before and would like to do it..... But maybe thats the point of the excercise, and this interface leans itself highly to sockets.... Especially in this issue....
I am going to begin working on that piece right now.. but maybe I might have to change my mind and not be so rigid, but pick whats better for the project.
Thanks for the discussion....
Roel De Nijs wrote:You could also make sure that subsequent calls made by a client are handled at the server by the same thread and then you can just use the id of the thread as a lockCookie.
Which, in my opinion, is the simplest path to follow, especially when the lock method does not return a value. You can find more information about this approach here.
Would the examiner still be able to use your implementation using a the existing Oracle specified interface?
I extended the interface myself to add a new close method but made sure all existing methods worked according to the specification. I had a different assignment to yours though.
If one can use your implementation of the DBMain interface in a method that expects the DBMain interface without collateral effects, then it is ok!
You could implement the lock/update/delete/unlock methods using the thread id to identify each client, the clientLock/clientUpdate/... methods are implemented using a generated lockCookie. This approach makes the existing methods useable when you have the guarantee that subsequent calls of a client are handled by the same thread. When you don't have that guarantee (like with RMI) you have to use the clientXxx methods. That's of course something you have to document. I think that's a better approach than mixing both implementations. I had something similar with a setClientId method (calling this method is only needed when you don't have the guarantee that a thread handles the subsequent calls of a client)
Hope it makes some sense!