File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Failed b/c of locking. Any ideas? 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 "Failed b/c of locking. Any ideas?" Watch "Failed b/c of locking. Any ideas?" New topic
Author

Failed b/c of locking. Any ideas?

David Miscia
Greenhorn

Joined: Feb 18, 2007
Posts: 3
Well I took the Developer exam and failed due to my locking/synchronization. I saw what I thought was the problem and corrected it...and failed again. I'm going to give it one more shot, but I can't see why I'm losing points. I'm working on the Bodgitt & Scarper contractor booking assignment.

This was the reason for failure:

- Major point loss for record-locking mechanism, which is not threadsafe. It is possible for multiple threads to concurrently obtain a lock on the same record.

I chose not to use a RandomAccessFile. Instead I keep all my record data in memory, in a DataContainer object which is just an array. Each thread gets a Data.java instance which has methods it can use to access the data in the data container ( read(), create(), modify(), delete(), etc.). After not passing, I basically made any code that I thought should be thread-safe synchronize on the DataContainer object containing the record data.

I realize this is not the best solution, but I thought it would at least solve the synchronization problem. I'm including the Data.java access class below. If any one wants to see any more code let me know. Help! I'm at a loss.

Sorry, it is not acceptable on this forum to post so much code (See our SCJD FAQ)
[ February 18, 2007: Message edited by: Barry Gaunt ]
Barry Gaunt
Ranch Hand

Joined: Aug 03, 2002
Posts: 7729
Welcome to JavaRanch, David.
It's tough, but I must apply the rules of the forum (see the SCJP FAQ) and edit out all your code, it was simply too much.

You may post your locking method, or your unlocking method but not both for discussion.


Ask a Meaningful Question and HowToAskQuestionsOnJavaRanch
Getting someone to think and try something out is much more useful than just telling them the answer.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18829
    
  40

I realize this is not the best solution, but I thought it would at least solve the synchronization problem. I'm including the Data.java access class below. If any one wants to see any more code let me know. Help! I'm at a loss.


Practically all of your methods -- read(), update(), delete(), lock(), unlock(), etc. -- have sections of code which uses the data variable without any synchronization. Remember, just because you don't change it, doesn't mean that you don't synchronize it. Some other thread could be changing it while you are calculating the index, giving you an invalid index.

Speaking of invalid index. Even when you do synchronize it, you are using an index that was calculated earlier before the synchronized block. How do you know that the index is still valid? What if another thread added or removed an entry?

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Khaled Mahmoud
Ranch Hand

Joined: Jul 15, 2006
Posts: 361
I wish you the best luck in your next submission.


SCJP, SCJD,SCWCD,SCDJWS,SCEA 5 MCP-C#, MCP-ASP.NET - http://www.khaledinho.com/
Life is the biggest school
Maciej Miklas
Ranch Hand

Joined: Feb 12, 2007
Posts: 61
Hi,

I am not sure if I got irt right, but sun ich checking the direct implementation of given DBMain interface.
So you have to be sure, that this is thread save. Does not mether, if you wrapp it, its methods directly has to be thread save.

Regards,
Maciej
Lucy Hummel
Ranch Hand

Joined: Apr 07, 2005
Posts: 232
Hi David,

Have you read the article [URL= http://www.javaworld.com/jw-08-1998/jw-08-techniques.html ]thread safety[/url]. I found it yesterday in the FAQs.

The article describes what was mentioned above that even in the get methods you have to use the synchronize function.

May I ask you to tell me, if you are going for a third try? I wonder if I would have the will and time to try it again.

Anyway, best Wishes from my side, Lucy


----------------------------------<br />| SCJP, SCWCD, SCBCD, SCEA, SCJD |<br />----------------------------------
Muhammad Shafique
Ranch Hand

Joined: Sep 30, 2006
Posts: 59
Hi Maciej,
I am not sure if I got irt right, but sun ich checking the direct implementation of given DBMain interface.


Are you sure that sun checks direct implementation od DBMain interface? Is is not mentioned in my assignment.


Shafique
David Miscia
Greenhorn

Joined: Feb 18, 2007
Posts: 3
Hi all, thanks for all the comments. I will definitely synchronize the code where I find the index, as I now see this also has to be thread safe. My worry is that the feed back from the corrector said that two threads could both obtain the lock on the same record. I just don't see how that is possible if every call to the lock() method is within a synchronized block of code, which synchronizes on the same common object. How is this possible?!

This whole synchronization thing was done to fix the thread safety. If all my code is in such a block, it pretty much invalidates the purpose of the lock/unlock methods, right? Probably bad coding but I'm trying to determine what they mean. I'm including my modify method below as an example...

Vincent Li
Greenhorn

Joined: Jan 12, 2007
Posts: 22
Hi David,

I think you are confused about the "lock/unlock" method versus the Java locking. The lock/unlock method simply tell your server "I am going to modify this record". When successful, no other thread/client will modify that record. But it does NOT mean you can modify it. This is where the thread safety issue comes in. You either use the synchronize, or the new 5.0 Lock or ReadWriteLock to tell other threads "I am actually modifying the data now", so no one else should be accessing the database while you find your record and change it. Only then do you release the "synchronized lock" to allow others to contiue operation. But at this point, you still haven't release the record for other to modify. That's when you call the unlock().

You are checking checking for the lock AFTER you try to locate the record. Well, that means someone else could have locked that record and deleted it while you are still looking for it and your "set" will fail. The "synchronized" locking is happening too late at that point.

Also, why are you doing a try-catch on the RecordNotFoundException? That code will never run. When you throw RecordNotFoundException just before the try, you would have gotten out of that routine.

Furthermore, if your "try" block could ever throw any exception, your unlock will never run. It must be put in a finally:



If that doesn't make sense to you, read up on exception handling, and you may not be ready for the SCJD yet!

Also, I think checking for network access or non-network access in Data is a bad idea. This means your Data class must know how it is being accessed and I think that's not its responsibility. It's responsiblity is to access the physical data in a thread safe manner, so it complicates your code. I understand you may think if you are in standalone mode, you don't need to synchronized. But think about it. If your code is synchronized, then running in stand-alone where you don't need to will still work. There is no need for the extra checking, especially performance is not critical.

If you truly intend to try a 3rd time, I would suggest you really really understand what is going on in the spec and what your code is doing first. If you resubmit this, you are wasting your money (though I'm sure Sun won't mind)!

...




-- Vince
SCJP(1.4),SCWCD(1.4), SCJD (almost there)
[ February 19, 2007: Message edited by: Vincent Li ]

Vince<br />SCJP(1.4), SCWCD(1.4), SCJD (5.0)
Rudolph Jen
Ranch Hand

Joined: Nov 17, 2006
Posts: 37
Multi-Threading is a not simple thing to implement. Therefor I would recommend, that you design a test suite that you can use to test your implementation of the DB-Interface. I would never only trust my feeling 100% just by looking at the code.

Best Regards,
R


SCJP<br />SCJD (in progress)
Lucy Hummel
Ranch Hand

Joined: Apr 07, 2005
Posts: 232
Hi David,

I agreee with Rudolph about testing. In the thread Topic: Recommended Approach For Testing Threads he already mentioned how he did his testing. I marked his hint already even if I have not started the SCJD right now.

In my past I did a lot of testing for my classes that I implemented and it helped a lot. I only can recommend to do testing as much as needed!

Lucy
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Failed b/c of locking. Any ideas?