aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes locking  approach Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "locking  approach" Watch "locking  approach" New topic
Author

locking approach

wu qiang
Greenhorn

Joined: Sep 07, 2005
Posts: 5
Hi
I have read some discussion in this forum. This thread by Philippe Maquet is very good . But My lock is different to Phillie's mention. So i can't ensure my approach is feasible. Sorry Andrew, I must post some code to explain my intent.Like you see ,It is only some simple paraphrase code. I hope someone give me some suggestion. Is it feasible?

[ September 07, 2005: Message edited by: wu qiang ]
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11278
    
  59

Hi Wu,

Welcome to JavaRanch and this forum.

Normally I would be deleting code from your posting since we don't allow that much code to be posted (see the JavaRanch SCJD FAQ for more details), however I have left it alone for the moment so that a number of issues can be discussed.

Why are you using Hashtable and Vector? What do these two classes provide you that one of the other collections wont give you?

It appears to me that two separate threads could add duplicate lock objects to the lockVector. So in theory if two clients tried to lock the same record simultaneously and that record has never been locked before, then both could succeed .

You don't seem to be verifying the cookie when you unlock a record.

Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
wu qiang
Greenhorn

Joined: Sep 07, 2005
Posts: 5
Thank you very much Andrew.I really appreciate your help.

Why are you using Hashtable and Vector? What do these two classes provide you that one of the other collections wont give you?

Yes .I prefer new collections to old .But this is a paraphrase code,so There are more factors I haven't considered yet .I use the old collections so that I dont'n need to consider the collections synchronization for the moment. Now i change my code. Is it ok .

if I do like this ,the dirty read is inevitable.

I think the dirty read can be avoid by using ReadWritelock.but this approch will increase the LockManager's complexity.
what do you think?

regards

[Andrew: Removed unlock method]
[ September 08, 2005: Message edited by: Andrew Monkhouse ]
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11278
    
  59

Hi Wu,
Originally posted by wu qiang:
I use the old collections so that I dont'n need to consider the collections synchronization for the moment.
Well you will have to consider that at some point . You can hardly expect to get opinions on code that you have not considered . I suspect that you have now considered your code - the fact that you have a synchronized map for your requestTable but the lockVector is not synchronized seems to indicate that you have thought it through. Several comments though:
  • You really should change the name of lockVector to something else: obviously it is not a vector any more. In fact, a lot of the variable names could do with being renamed to make them more obvious.
  • Implementation comments could be very useful here, otherwise the junior programmer might not realise why requestTable is a synchronized collection.
  • Following the Sun Code Conventions for the Java Programming Language will make it much easier to read your code
  • Have you noticed that I have not really picked on what the code is doing?

    My biggest issue now is the handling of the InterruptedException. When could this be called? Who could have interrupted your thread? What might they expect to have happen?

    Originally posted by wu qiang:
    I think the dirty read can be avoid by using ReadWritelock.but this approch will increase the LockManager's complexity.
    what do you think?


    A ReadWriteLock will certainly solve that issue for you, but if you are using JDK 5 then I might start picking on other parts of your code (such as not using generics / not using autoboxing / ...)

    I don't think dirty reads are a problem. No matter what you do, there exists the potential for data displayed in the client GUI to be different from the data stored in the physical database. You might like to take a look at "Why are dirty reads ok?"

    Regards, Andrew
    wu qiang
    Greenhorn

    Joined: Sep 07, 2005
    Posts: 5
    Thank you very much Andrew.
    I think your suggestion is very useful.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: locking approach
     
    Similar Threads
    pls validate my locking strategy - all inputs are g8ly appreciated. (URLyBird)
    Why I lost points in locking, pls comment on my code
    Lock on reading records
    nx:All of URLy Bird1.1.3 about record lock
    more locking