Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Wrapper methods for lock, update etc -- extension og DBMain

 
S. Thakker
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

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.

Question:

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..
 
Roberto Perillo
Bartender
Posts: 2271
3
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Greetings, champ!

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.
 
S. Thakker
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Roel De Nijs
Sheriff
Posts: 9828
103
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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

 
S. Thakker
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes Roel,

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

synch
{
client=data.setClient(generateClientId())
lock
}

synch
{
data.setClientId(client)
update
}

synch
{
data.setClientId(client)
unlock
}

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

Thanks for the reply, I appreciate your time..
 
Roel De Nijs
Sheriff
Posts: 9828
103
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
S. Thakker
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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....
 
Roberto Perillo
Bartender
Posts: 2271
3
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Chris Zaremba
Ranch Hand
Posts: 54
Eclipse IDE Linux Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
S,

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.

 
Roberto Perillo
Bartender
Posts: 2271
3
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!
 
Roel De Nijs
Sheriff
Posts: 9828
103
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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)

Hope it makes some sense!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic