Forums Register Login

Failed b/c of locking. Any ideas?

+Pie Number of slices to send: Send
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 ]
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
 

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
+Pie Number of slices to send: Send
I wish you the best luck in your next submission.
+Pie Number of slices to send: Send
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
+Pie Number of slices to send: Send
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
+Pie Number of slices to send: Send
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
+Pie Number of slices to send: Send
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...

+Pie Number of slices to send: Send
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 ]
+Pie Number of slices to send: Send
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
+Pie Number of slices to send: Send
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
Or we might never have existed at all. Freaky. So we should cherish everything. Even this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 1216 times.
Similar Threads
Bodgitt and Scarper : locking and unlocking
OCMJD - Bodgitt and Scarper Questions!
recNo in Bodgitt and Scarper
NX: Bodgitt and Scarper and design/synchronization questions
Locking & Synchronization on Bodgitt & Scarper
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 29, 2024 07:29:46.