aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Wrapper methods for lock, update etc -- extension og DBMain Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Wrapper methods for lock, update etc -- extension og DBMain" Watch "Wrapper methods for lock, update etc -- extension og DBMain" New topic
Author

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

S. Thakker
Ranch Hand

Joined: Aug 11, 2011
Posts: 45
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

Joined: Dec 28, 2007
Posts: 2247

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.


Cheers, Bob "John Lennon" Perillo
SCJP, SCWCD, SCJD, SCBCD - Daileon: A Tool for Enabling Domain Annotations
S. Thakker
Ranch Hand

Joined: Aug 11, 2011
Posts: 45
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
Bartender

Joined: Jul 19, 2004
Posts: 4925
    
  10

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


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
S. Thakker
Ranch Hand

Joined: Aug 11, 2011
Posts: 45
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
Bartender

Joined: Jul 19, 2004
Posts: 4925
    
  10

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

Joined: Aug 11, 2011
Posts: 45
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

Joined: Dec 28, 2007
Posts: 2247

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

Joined: Nov 22, 2010
Posts: 54

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.


SCJA, OCPJP, OCMJD
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2247

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
Bartender

Joined: Jul 19, 2004
Posts: 4925
    
  10

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!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Wrapper methods for lock, update etc -- extension og DBMain
 
Similar Threads
URLyBird 1.3.2: Where do you call the Data class's lock() and unlock() method?
Locking
NX: Should I call lock method before searching records?
NX: [UrlyBird 1.3.1] - locking and [client] thread death
Lock Method Issue