This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
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.
Thanks Robert for your response... I am still a bit apprehensive about adding those methods... normally I wouldnt think twice, but in this case, maybe I will
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.
Does the lock-method in your interface already returns a lockCookie? Based on your question I think it does not and you are trying to add one to your interface by adding some similar methods. Otherwise I would have no idea why you are adding these methods.
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
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. 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.
Joined: Aug 11, 2011
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.
Alright, so I think there should be no worries. Roel and I also extended the interface that was provided to us. Other people choose to use the Data class as a facade and put the inteligence of the methods in classes that stay "underneath" it.
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!
I think there is not a problem with extending the given interface, but maybe there would be with the solution provided in the original post. Because it seems to me the lock method (also update, delete and unlock) becomes unusable. Because if you decide to use the lock-method, a lockCookie is added to the lockedRecords map but you can't retrieve it. So each client can update the locked record, because when you use the update method there can only be a check to see if the record is locked, not if it was locked by the client which tries to update the record. And that could be a problem in my opinion.
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)