• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Can someone check my lock/unlock methods, please?

 
Rob Shields
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Please can you check the following methods and let me know if there is anything wrong with the locking. The other implemented method (read, create, update, find) bodies are also all wrapped in a synchronized (raf)


Thanks,
Rob




[ October 12, 2004: Message edited by: Rob Shields ]

[Andrew: 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. 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.]
[ October 12, 2004: Message edited by: Andrew Monkhouse ]
 
Omar Kalaldeh
Ranch Hand
Posts: 58
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
what is raf? I am assuming its the file object.
I think You should put the synchronization block on the Map object.


No need to throw exception when waiting thread get Interrupted.


Should throw securityException not IllegalArgumentException.

[ October 12, 2004: Message edited by: Omar Kalaldeh ]

[Andrew: changed line wrapping]
[ October 12, 2004: Message edited by: Andrew Monkhouse ]
 
Hu Yong Jun
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think it is very good.

I have almost accomplished my assignment.

I have a LockCookieGenerator to generate the unique cookie.
I turn the concept of DataAdapter into session facade so that the Data is a singleton. So I can use "synchronized" on the Data object, say the methods in Data modifying database are synchronized. I also model the lock as a object, not a pair of cookie/recNo values.

My design is not the good maybe. I hope that I could pass the exam.
[ October 12, 2004: Message edited by: Hu Yong Jun ]
 
Rob Shields
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi

what is raf? I am assuming its the file object.

Yes, it's the RandomAccessFile instance I'm using to read, write and seek.

I think You should put the synchronization block on the Map object.

Just for the lock and unlock methods, or for all of them? What is the reason for this?

No need to throw exception when waiting thread get Interrupted.

Should I just log it instead?

Should throw securityException not IllegalArgumentException.

D'oh! I was wondering what the SecurityException was for..

Thanks for your help.
Rob
 
Rob Shields
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi


I have a LockCookieGenerator to generate the unique cookie.
I turn the concept of DataAdapter into session facade so that the Data is a singleton. So I can use "synchronized" on the Data object, say the methods in Data other than modifying database are synchronized. I also model the lock as a object, not a pair of cookie/recNo values.


Yes, I was thinking of having the data object as a singleton and synchronised that, but it says in the requirements:

You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server.


So I took that to mean there was no need to make a singleton, although I'm thinking of making one anyway just to be sure

It sounds like you have gone to more effort with the cookie generator na dlock object. I'm trying to do the bare minimum to meet the requirements, on the basis that I'm less likely to make mistakes that way.

Regards,
Rob
 
Omar Kalaldeh
Ranch Hand
Posts: 58
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Just for the lock and unlock methods, or for all of them? What is the reason for this?


Just for the lock and unlock,
Reason for that, I will try to explain it, but I can�t promise you much, I find it hard to explain threads in words.

Doing it in your way it will be almost as same as setting synchronizing on the data methods.

You want your waiting thread to wake up when ever a specified record get unlocked.
So the key operations for waiting/notify is lock/unlock.
When you unlock a record you want only the threads waiting for unlock to wake up, you want the competing be in the lock base not on database base.

Let say you have thread A waiting to lock a record, and this record is locked by another thread B, when B unlocked the record, another thread, let say C came and called read method then it will acquired the file object and the thread A will not be able to acquired the file object, and will keep waiting.

But if your Synchronized blocked was on the map object, when thread C call read method, thread B will still be able to continue its locking operation.

I am not sure if the picture gets clear.

[ October 12, 2004: Message edited by: Omar Kalaldeh ]
[ October 12, 2004: Message edited by: Omar Kalaldeh ]
 
Rob Shields
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi

Originally posted by Omar Kalaldeh:

I am not sure if the picture gets clear.


Yes, perfectly clear, thankyou

So my lock and unlock methods now look like:



The other methods are still synchronised on the RandomAccessFile instance.

Thanks for your help.
Rob

[Andrew: 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. 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.]
[ October 12, 2004: Message edited by: Andrew Monkhouse ]
 
Ya Zhang
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all:
I just writing my lock and unlock method. I saw that many people synchronized the LockMap, I want to konw what different between using the synchronized the LockMap and synchronized at method? likes public synchronized lang lock(int recNo), and which way is better?
[ October 19, 2004: Message edited by: Ya Zhang ]
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12007
215
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ya Zhang,

Welcome to JavaRanch and this forum.

There are many factors influencing which way to write your synchronized code.

One thing to be aware of is that synchronized blocks have a performance overhead, and are a bottleneck. So there is always a choice to be made which way you want to handle synchronized code. Having two synchronized blocks within the one method means that you will encounter that performance bottleneck twice, however it also means that you are reducing the amount of code which is inside synchronized blocks, which means that overall you may get better performance.

Having the one synchronized method, on the other hand, makes it easier to avoid potential deadlock situations (e.g. where one thread owns the mutex on the file and is waiting for the mutex on the LockMap, while another thread owns the mutex on the LockMap and is waiting for the mutex on the file). But then you have the performance issue again - you probably will end up with code inside your single synchronized method that does not need to be synchronized. So you will end up with a small bottleneck.

Another advantage of multiple synchronized blocks is that you can synchronize on different objects. If you are synchronizing the entire method, you are effectively synchronizing on the instance of the class. For those users who have multiple instances of their Data class this may not be acceptable - they must use common objects in order for locking to work. You might also want to consider it simply because the record locking code should be able to work independantly of the file access code - if you have two separate mutexes this is possible. If you only have the one mutex, then while someone is locking a record no-one can access a file - or while someone is accessing a file, no record locks can be granted.

So you can (hopefully) see that there are a lot of factors influencing this sort of design decision. What might be right for you could be completely wrong for someone else. You have to make your own decision (talking your ideas through with others in this forum is a good idea ) and then document your decision.

Regards, Andrew
 
Jared Chapman
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ya Zhang,

I want to konw what different between using the synchronized the LockMap and synchronized at method? likes , and which way is better?


I also synchronized on the lock map. In my implementation, each client gets its own Data object to access the database with. Also, all of the methods in my Data class are non-static. Therefore, these methods only provide synchronization for a particular instance of the Data class.

For example, if we have two instances of Data, called d1 and d2, then calling d1.lock(recNo) does NOT stop d2.lock(recNo) from running.

As a solution, you can use a STATIC HashMap in your Data class that will store the locked records. This static HashMap will be shared by ALL instances of Data. Inside your lock method, put a synchronized block (synchronizing on the HashMap). Then, calling d1.lock(recNo) and
d2.lock(recNo) will cause both instances of data to attempt to grab the lock of the single static HashMap. One will succeed, the other will wait.

Hope this helps.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic