lock & unlock advice

[Allan Cheong]

--

[Roel De Nijs]

Hi Allan,

It is not allowed to post your locking mechanism algorithm (please take a look here). So I would advice you to delete it completely. And if you want to check if your locking mechanism is working correctly, try using the great test case of Roberto Perillo, which you can find here. So you'll can find out for yourself if it is working or not.

[edit] didn't read your post thoroughly enough, you already used Roberto's thread. My apologies. One of the most common problems in the locking mechanism (which I made myself too) is: before locking a record, you still have to verify if it still exists, because the lock() method works for both updating and deleting a record, so it may have been deleted. The advice for deleting your complete locking mechanism (because that's not pseudo-code) still stands!

Kind regards,
Roel

[Allan Cheong]

Sorry for my previous post. I have no one to turn to for advice.

[Roberto Perillo]

Howdy, Allan!

First, you are very welcome!

Second, please take Roel's considerations. It's just that it is not allowed to post real parts of the assignment (as he's shown you already). When we take a certification, we agree in not publish anywhere real parts of it. Please remove it, or post some pseudo-code that can minimally show your doubt so everybody can help you as still stick to the rules.

Third, yes, Roel is correct. You are not verifying if the record is still valid before locking it (it may have been deleted).

Fourth, since your Data class is not a Singleton, then everytime you say new Data(), then an entire structure is created in memory. So, even though you say synchronized(this), the other Threads will deal with other objects, not "this", so it isn't of much use. If you don't want your Data class to be Singleton, then you can use it as a Facade, and deal with other class that controls the locking mechanism. But it has to be unique for the entire application, so it will have to either be Singleton, or at least the object that controls the locked records will have to be static.

[Allan Cheong]

Thank you both for your guidance. I will not repeat that in future.

What do you think if I check if the record is valid in the lock() and unlock() method before doing update/delete?

[Roel De Nijs]

Hi Allan,

You can post some few lines of code or some method in pseudo code, but not your complete lock and unlock method, because it's the hardest part and other people then simply could copy your solution (and that's not the purpose of the scjd assignment). And your methods were not really pseudo-code, but just good old Java.

You didn't have to delete your complete post, just remove the code snippets of your lock/unlock methods.

I have no one to turn to for advice.

My advice for my previous post still stands (and applies to your code): before locking a record, you still have to verify if it still exists, because the lock() method works for both updating and deleting a record, so it may have been deleted.

I saw Roberto has already pointed out some other excellent point, so I will not repeat the same issue (I had some visitors passing by, so couldn't finish my post).

What do you think if I check if the record is valid in the lock() and unlock() method before doing update/delete?

This is pseudo-code of how your lock method should be implemented:

check if recNo exists (optional)

check if recNo is already locked (if it is, wait until it gets unlocked)

check if recNo exists (required, because another thread which was holding the lock may have deleted this record)

generate lockCookie and add to the map with locked records

Kind regards,
Roel

[Allan Cheong]

 

Roel De Nijs wrote:check if recNo exists (optional)

Yes, I only implemented this check. I changed the code to check again after getting the lock and it seems more logical now. This will ensure the delete/update method will not throw RNFE.

Roberto Perillo wrote:Fourth, since your Data class is not a Singleton, then everytime you say new Data(), then an entire structure is created in memory.

Then can I synchronize on Data.class instead of Data instance? Or actually I can create another Singleton object purposely just for the wait()/notify() method? (It's a bad design I know). What I mean is it doesn't matter on which object it is synchronized on as long as it is shared across threads and every threads are looking at the same instance isn't it? Because all we need is to get the "common" lock.

[Roel De Nijs]

Hi Allan,

Seems you missed some bracket in the quote-tag in your previous post

What I mean is it doesn't matter on which object it is synchronized on as long as it is shared across threads and every threads are looking at the same instance isn't it?

That is spot-on.

You could do something like this:

class Data {
private static final Object OBJECT = new Object();
// somewhere in a method
synchronized(OBJECT) {
OBJECT.wait();
}
}

The OBJECT will be shared by all instances of Data. But of course you have to wonder if making the Data class a singleton doesn't make more sense...

Kind regards,
Roel

[Allan Cheong]

 

Roel De Nijs wrote:Seems you missed some bracket in the quote-tag in your previous post

Ops my bad.

I am still waiting for the Apress SCJD book I ordered to arrive. Hopefully I can get a better understanding on how the lock/unlock should be done.

By the way, Merry Christmas guys.

Cheers,
Allan

[Roberto Perillo]

Howdy, Allan!

I am still waiting for the Apress SCJD book I ordered to arrive.

Great acquisition! In the book, it is very well explained everything you have to know about Threads and locking.

One thing I realize is that people tend to think the locking mechanism is the hardest thing of the world. It isn't. So, keep things as simple as possible and you'll do well!

Merry Christmas, everyone!!!

[Roel De Nijs]

 

Roberto Perillo wrote:One thing I realize is that people tend to think the locking mechanism is the hardest thing of the world. It isn't.

I disagree: for me the locking mechanism was the hardest part, but once you are completely familiar with it and you have a working implementation you don't have any idea why you were struggling with it because you just need some common sense and think logical about it and you'll do fine. But that's almost true for anything: first driving a car seems so difficult, but once you have driven a lot it is just a habit and you can do it with your eyes closed

Merry Christmas to you too, Roberto!

Kind regards,
Roel