aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes NX: URLy Bird 1.3.1 Hashmap (or Hashtable) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "NX: URLy Bird 1.3.1 Hashmap (or Hashtable)" Watch "NX: URLy Bird 1.3.1 Hashmap (or Hashtable)" New topic
Author

NX: URLy Bird 1.3.1 Hashmap (or Hashtable)

Bharat Ruparel
Ranch Hand

Joined: Jul 30, 2003
Posts: 493
Hello,
I have been going through the posts on this forum and I have gone through Max's book. I have seen serveral posts and discussions on using a HashMap (sometimes a WeakHashMap) instead of a vector or an ArrayList to lock the threads.
Max's book uses a vector to keep track of locked records which makes perfect sense to me. I am a bit confused about using a HashMap here. Any clarifications will be of great help to me.
Thanks.
Bharat


SCJP,SCJD,SCWCD,SCBCD,SCDJWS,SCEA
Bharat Ruparel
Ranch Hand

Joined: Jul 30, 2003
Posts: 493
Hello Phil/Andrew/Bala/Vlad,
Any takers?
Bharat
S Bala
Ranch Hand

Joined: Jul 15, 2003
Posts: 49
HI Bharat,
I used Hashmap for URLyBird to store a lock and associated lockcookie. If I had stored the lock in a List, then everytime, I will have to iterate through the List to see if a lock exists or to find a lockcookie. I was not sure whether I could write an algorithm which was `really fast. Instead, I made use of the methods available in HashMap (containsKey, getValue). The underlying implementations of the API might very well be one with iterators, but it will be much fatster - IMO.
-Shankar
Bharat Ruparel
Ranch Hand

Joined: Jul 30, 2003
Posts: 493
Hello Shankar,
Thanks for the reply. It seems to me that I may not have to use a HashMap and I can get by with a Vector or ArrayList because the interface that I need to declare for URLy Bird 1.3.1 is as follows:
package suncertify.db;
public interface DBMain {
// Reads a record from the file. Returns an array where each
// element is a record value.
public String [] read(int recNo) throws RecordNotFoundException;
// Modifies the fields of a record. The new value for field n
// appears in data[n].
public void update(int recNo, String [] data)
throws RecordNotFoundException;
// Deletes a record, making the record number and associated disk
// storage available for reuse.
public void delete(int recNo) throws RecordNotFoundException;
// Returns an array of record numbers that match the specified
// criteria. Field n in the database file is described by
// criteria[n]. A null value in criteria[n] matches any field
// value. A non-null value in criteria[n] matches any field
// value that begins with criteria[n]. (For example, "Fred"
// matches "Fred" or "Freddy".)
public int [] find(String [] criteria)
throws RecordNotFoundException;
// Creates a new record in the database (possibly reusing a
// deleted entry). Inserts the given data, and returns the record
// number of the new record.
public int create(String [] data) throws DuplicateKeyException;
// Locks a record so that it can only be updated or deleted by this client.
// If the specified record is already locked, the current thread gives up
// the CPU and consumes no CPU cycles until the record is unlocked.
public void lock(int recNo) throws RecordNotFoundException;
// Releases the lock on a record.
public void unlock(int recNo) throws RecordNotFoundException;
// Determines if a record is currenly locked. Returns true if the
// record is locked, false otherwise.
public boolean isLocked(int recNo)
throws RecordNotFoundException;
}
This does not have cookies unlike other versions of URLy Bird. Therefore, it seems to me that I only need to keep track of the record numbers that are locked and I can do that either in an ArrayList or Vector?
Thanks for the quick response.
Regards.
Bharat
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11481
    
  94

Hi Bharat
You do need to remember that Max's book is working on a slightly different problem than the one you are working on for the assignment. So his choice of how to handle any particular issue may not necessarily be the same one you need to choose.
Somewhere in your application, you are going to have to track ownership of locks, and ensure that only the person who locked a record can modify it or unlock it.
If you are tracking that in the Data class, then you will need to store something to identify the owner along with the record number. That would tend to indicate a Map of some sort. If you are tracking this elsewhere, then you may not need a map.
If you have decided that you do not need a map, then when comparing Vectors to ArrayLists (or even Sets), you need to work out what one gives you over the other. Vectors are from the old Collections, and are internally synchronized. This could be a benefit, but it is more likely to be unnecessary overhead - you have to decide that for yourself depending on how you use them.
Regards, Andrew
[ August 11, 2003: Message edited by: Andrew Monkhouse ]

The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Vlad Rabkin
Ranch Hand

Joined: Jul 07, 2003
Posts: 555
Hi Bharat,
I agree with Andrew.
It depends on your overall solutions.
I stored record numbers and its cookie to maintain locks.
It is much easier to find appropriate lock (by record number) by using a HashMap.
List can be a better solution if you want to store there threads or something else (depending on your solution) to organize for example FIFO
queue for locks.
You should choose appropriate Collection depending on your architecture.
Vlad
Bharat Ruparel
Ranch Hand

Joined: Jul 30, 2003
Posts: 493
Hello Andrew,
Thanks for the response. I haven't decided anything yet. I am more in the mode of trying to understand why am I doing certain things. The things that I can base that on are 1. Max's book & 2. Various Posts and threads on this forum.
The reason that I thought (and still think) that my problem was somewhat similar to the one solved in Max's book is the absence of the cookie parameter in method signatures of the DBMain.java interface given in my assignment. It also seems to me (gleaning as much information as I can from the related posts and answers on the forum) that I can pretty much treat the record numbers as primary keys. Therefore, a Vector (or ArrayList if I don't need internal synschronization of the methods) should be sufficient to identify the records that are currently locked (shouldn't really have to worry about by who).
I guess in absence of cookies, I don't understand why should I worry about the thread ownership. May be there is something fundamental that I am missing here. My understanding of how locking works is that as long as on of my application's threads is successful in acquiring the lock on the record that it is trying to modify (or logically delete), it can do its job and then notify the waiting threads that it is done. Anyone of the waiting threads will be given an opportunity to acquire the lock now based the scheduling algorithm that the underlying operating system uses. Therefore, I thought that it was sufficient for me to track the record numbers only; in a data structure such as a Vector or an ArrayList. Since anyone of the waiting threads can acquire the lock and only that particular thread that acquired the lock in the first place (by entering the synchronization block) will be allowed to unlock (upon exiting the synchronization block).
Look forward to your reply.
Thanks.
Bharat
Bharat Ruparel
Ranch Hand

Joined: Jul 30, 2003
Posts: 493
Hello Vlad,
I appreciate your reply as well. It came through while I was replying to Andrew. You will see my logic in that reply. I agree with you that a Map structure is more appropriate to lookup a value based on a key. But if I don't have to look-up a value (a cookie) based on the record number, since I only have record numbers then what value does the Map structure add? I am really confused about why do I have to track the ownership of a thread since that is not in my problem statement.
Thanks.
Bharat
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11481
    
  94

Hi Bharat
The issue about who owns the lock may not apply - it all depends on how you code your solution.
If you have the client code call the "lock, read, update, unlock" methods, then you will need to track who owns the locks, to ensure that an unscrupulous client does not update a record without locking it first, or try to unlock a record they have not locked.
However if you have the client code call a "book" method on the server, where the book method on the server calls the "lock, read, update, unlock" methods, then those issues are not possible.
There are good and bad points for both options. You will have to think about them, and decide which one you are going for (and document your decision ).
Regards, Andrew
[ August 13, 2003: Message edited by: Andrew Monkhouse ]
Vlad Rabkin
Ranch Hand

Joined: Jul 07, 2003
Posts: 555
Hi Bharat,
But if I don't have to look-up a value (a cookie) based on the record number, since I only have record numbers then what value does the Map structure add?

No value at all!
That is what me and Andrew are saying: it deends on your solution. If you don't want to collect record number / cookie pairs - List is a better solution.
Vlad
Bharat Ruparel
Ranch Hand

Joined: Jul 30, 2003
Posts: 493
Andrew/Vlad,
Thanks gentlemen for your help. I am leaning towards the serverside locking since:
1. It is simpler
2. It is cleaner
3. My requirements are such that I can get by only server-side locking; I am doing 1.3.1.
4. That is how the good (Max's book) explains it.
I will be back with more questions after this Saturday's design/programming session in the library.
In the meantime though, I do have a question: Vlad, are you saying that even if I decide to implement the serverside locking and even though I don't have cookies to validate the authenticity of a client thread, I am better off using a hashmap since it facilitates direct access based on record numbers? That I can leave the value out all-together (keep nulls)? Now going a bit further, then as others are suggesting on this forum, use a WeakHashMap since it will release locks in the event of a thread failuare and be garbage collected.
Andrew, please feel free to comment. You are a great teacher.
Thanks again gents. This is turning into a great learning experience.
Regards.
Bharat
Vlad Rabkin
Ranch Hand

Joined: Jul 07, 2003
Posts: 555
Hi Bharad,
Vlad, are you saying that even if I decide to implement the serverside locking and even though I don't have cookies to validate the authenticity of a client thread, I am better off using a hashmap since it facilitates direct access based on record numbers? That I can leave the value out all-together (keep nulls)? Now going a bit further, then as others are suggesting on this forum, use a WeakHashMap since it will release locks in the event of a thread failuare and be garbage collected.

I think we talk about different things:
First you have to decide how locking mechanism should work.
Second , how it should handle (if should) client crash.
Client crash:
There are two approaches which have been discussed:
- HashMap in connection object (remote object) which keeps track of all active locks by the user (you can also use List if you want), which is not the same collection where you hold all record locks. I use HashMap in connection object having all active lock of the caller, which will be released if the client crashes and another HashMap in LockManager having all locks of all caller, but it is my solution. You can still have HashMap in connection object and List in LockManager or only one List or HashMap.
It depends on your design!
- WeakHashMap
Both approaches have advandages and disadvantages.
You would better look directly on this thread.
If you want to use lock/unlock on your server (there will not be available in the client interface) I have doubts whether you should be concerned about client crash, since lock/unlock will called from your business server, but not client.
Collection for locks:
As I said: I do use HashMap, because I need to keep track of cookies.
Let's say update method is called. I have to check whether the caller is the owner of this lock. To do it I have to get cookie by record ID. HashMap is perfect to do it.
If your design manages to keep track of locks without need to hold the cookies or you have one object containing reference to record number AND cookie you can use List. If you don't lock/unlock on client, but on the server, I don't think you need to take care of dead-lock because of client crash, so I don't need WeakHashMap or something else. It just my personal opinion.

Regards,
Vlad
Bharat Ruparel
Ranch Hand

Joined: Jul 30, 2003
Posts: 493
Hello Vlad,
Thanks your the explanation. The fog is beginning to lift! A dumb question, What is a connection object? Is it the RMI implementation object?
Appreciate your time.
Bharat
Vlad Rabkin
Ranch Hand

Joined: Jul 07, 2003
Posts: 555
Hi
Thanks your the explanation. The fog is beginning to lift! A dumb question, What is a connection object? Is it the RMI implementation object?

Sorry, I forgot to specify it. Yes, it is. In the discussion between Max and
other they call it connection object. It is a remote object.
It is a bit hard to explain it on basis of all possible designs suggested.
Let me take an example of mine:
I have remote object per client connection (some people have a single remote objects, you can make also a pool of objects etc.). So this remote object reffers (in my case) to the client session.
In case of HashMap solution for example this Remote object Class implements UnReferenced Interface. The method unreferenced() releases all active locks of the caller (the client referencing this remote object).
So, if the client crashes, RemoteObject becomes after some time (when lease is expired) unreferenced. If the client locked some records and crashed all these locks will be realeased. If I had not do it, the record would be locked forever (except Server restart ).
This HashMap in Remote Object has nothing to do with HashMap in the LockManager used by Data class. I need to hold in the hashMap record number and cookies to be able to unlock records (I cannot unlock a record without knowing the cookie).
But remember it is my design:
- lock/unlock is invoked by the client application, not a server;
- I have remote objects per client connection
All what I said is a good solution for my design, it is not necessary good
for yours one!
Take a look at the thread about LockManager. They have argued all possible solutions around one week. It is like a tutorial.
Vlad
 
 
subject: NX: URLy Bird 1.3.1 Hashmap (or Hashtable)