aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes NX:another solution for lock issue 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 "NX:another solution for lock issue" Watch "NX:another solution for lock issue" New topic
Author

NX:another solution for lock issue

janvy wei
Greenhorn

Joined: Jan 03, 2004
Posts: 28
Hi,Fellow Ranchers.
I know that most ranchers use something like lock manager to lock and unlock records.
This solution works fine but seems innecessary to use an additional class to lock and unlock records,IMO.And the solution may synchronize a big object if there's many records in the database,which bring some performance issues.
So,I use another solution.
First I used a Contractor class to put an O-O framework around the String arrays that reprent the record data.The Contractor class has a long field called lockCookie,which is the cookie the record is locked with,and lockCookie is -1 indicate that the record isn't locked.
Then,my lock and unlock method in the Data class is below:

Is there anything wrong with my solution?Any opinion is appreciated.
[Andrew: Removed some of the code]
[ April 09, 2004: Message edited by: Andrew Monkhouse ]
Stephen Galbraith
Ranch Hand

Joined: Oct 27, 2003
Posts: 90
I've had a quick look and it seems okay.
However your getRecord() method...
What would happen if one thread gets part way through this method and switches out and another thread comes in with the same recNo. You basically need to ensure that the "contractor" returned is the same object(not just same insides!) no matter what thread calls it, so you'll need some caution here.
As for other ranchers - we all don't have lock cookies, so I need to keep track of who has what lock in other way - hence I use LockManager.
Steve.


SCJP 1.4, SCJD, SCWCD 1.4
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11483
    
  94

Hi Janvy,
I have removed some of your posted code, as we do not allow major sections of the assignment to be posted in this forum. The locking code is worth 20% of the assignment, and this is far too much to post in total.
There are multiple reasons for this policy:
  • Sun do not allow you to share your assignment or a solution to the assignment with others.
  • You have spent time and effort getting your solution right. It would not be right for someone else to just copy your solution without working it out for themselves.
  • If someone did get awarded the SCJD certification after copying your code, and were then given employment because they had that certification, the employer would probably find that the employee cannot actually do the work. Which makes the perceived value of this certificate decrease.
  • If people post too much code, then Sun may, in the future, request that we do not allow any SCJD code to be posted.

  • This policy is described in the question "What is the policy on posting questions I saw on the exam / details of how to do the assignment?" in the JavaRanch SCJD FAQ.
    Sorry, I do not have time to look at and comment on your code at present - hopefully tomorrow.
    Regards, Andrew


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

    Joined: Jan 03, 2004
    Posts: 28
    Hi,Stephen.
    Thanks for you reply.
    The getRecord() method will just return a Contractor instance from the cache which is a List without changing the cache's structure,so I think the
    method will be thread-safe.
    janvy wei
    Greenhorn

    Joined: Jan 03, 2004
    Posts: 28
    Hi,Andrew.
    Sorry for my careless.You do the right thing.
    And I am waiting for you opion.
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11483
        
      94

    Hi Janvy,
    Just some minor comments.
    Why are you generating the lock cookie inside your synchronized block?
    There is always a tradeoff between reducing code within the synchronized block to the bare minimum that needs to be synchronized (improving concurrency) and doing work at the latest logical time (improving readability). Whatever you decide to do is fine, just so long as you have thought about it.
    Why are you reloading the contractor within the while loop:

    If you do get an InterruptedException, the code which called the lockRecord() method will get back a lockCookie - is this reasonable?
    Regards, Andrew
    janvy wei
    Greenhorn

    Joined: Jan 03, 2004
    Posts: 28
    Hi,Andrew,thanks for you reply.
    1)
    Originally posted by Andrew Monkhouse:

    Why are you reloading the contractor within the while loop:



    en,it's a bug.thanks!
    Originally posted by Andrew Monkhouse:

    Why are you generating the lock cookie inside your synchronized block?
    If you do get an InterruptedException, the code which called the lockRecord() method will get back a lockCookie - is this reasonable?


    The two questions have the same answer,as you know,I use -1 indicates that the contractor isn't locked,so if get an InterruptedException,the method will return -1 represents that the contractor wasn't locked yet,then the method which invokes lock should do something for it.That also is why I generate the lock cookie inside the synchronized block.
     
    wood burning stoves
     
    subject: NX:another solution for lock issue