“Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.” - Rich Cook
----------------<br />SCJP (98%)<br />SCJD (81%)<br />SCEA (near future)
I'm wondering, what did u do to avoid that a record be locked forever when it is locked by a process and then that process dies.
It can never release its lock then ?
----------------<br />SCJP (98%)<br />SCJD (81%)<br />SCEA (near future)
I was lead to believe that that made a whole lot of difference.
a bunch of books and some people keep on warning about processes locking records and never releasing them.
What I'm wondering, did u also use a lot of objects,
or did u prefer a fast primitive typed solution ?
----------------<br />SCJP (98%)<br />SCJD (81%)<br />SCEA (near future)
This is mostly speculation about what can cause the mysterious 44/80 score - nobody knows for sure yet. I, like some others on this site, believe that managing for orphaned locks is outside the scope of this project. Ryan's score seems to support this theory. Again, I hope some of the people who have scored 44/80 will give us a detailed explanation of their locking solution so we can compare it to Ryan's.I was lead to believe that that made a whole lot of difference.
a bunch of books and some people keep on warning about processes locking records and never releasing them.
“Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.” - Rich Cook
For update, first I check if the record is being locked by the specified cookie within the HashMap sync block. Then I perform the actual I/O update out of the sync block.
For delete, I do similarly as update, but include another HashMap sync block after delete to remove the locked record.
Are you synchronizing on your HashMap within your update method? If so, why? It makes no sense to me to do such if all you are doing is a lookup. My understanding is that you should only synchronize the HashMap (or whatever locking structure you may have) during times you plan to delete (during unlock) or add (during lock) operations.
If multiple threads access this map concurrently, and at least one of the threads modifies the map structurally, it must be synchronized externally.
Again, I'm not sure what you mean by this. Are you talking about your unlock record operation? Also, shouldn't unlockRecord handle the deletion of the locked record number?
Originally posted by Ryan Tang:
Hashtable is somehow a "legacy" data structure in Java. HashMap is newly introduced in Java Collection Framework with Java 1.2.
You can have a look on this for more details.
----------------<br />SCJP (98%)<br />SCJD (81%)<br />SCEA (near future)
SCJP 1.4, SCJD
More than that, for this use there is a real reason not to use a synchronized collection. You need to have you own synchronized methods or blocks so that you can use wait and notifyAll. These blocks will access the collection. If the collection is also synchronized, you will have nested synch blocks, which are a bad idea since they encourage deadlocks and they interfere with performance.
Hashtable is somehow a "legacy" data structure in Java.
Originally posted by Frans Janssen:
Frank,
If I understand your design correctly, your building a so-called thin client, where the business logic is all implemented server side, e.g. a book method.
This defies the need for a lock() method in the interface, as your description confirms. For this reason a lot of people, including myself, assume that this design is not what Sun describes as "a traditional client-server system". There are numerous threads on this issue on this forum.
On the other hand, people have passed using similar designs, so second-guessing Sun's deeper motives is maybe taking the assignment to seriously![]()
Although I feel that your design deviates from the direction that your instructions point us, I see no flaws design-wise.
Frans.
SERVER
Required Interface
Your data access class must be called "Data.java", must be in a package called "suncertify.db", and must implement the following interface:
----------------<br />SCJP (98%)<br />SCJD (81%)<br />SCEA (near future)
Originally posted by Frank Verbruggen:
This means that for accessing my data, server-side ! I must have a clasds called "Data.java" in package "suncertify.db", NOTHING is mentioned about having to expose this interface to the clients !!!
So I plan not to.
Comments ??
SCJP 1.4, SCJD
Originally posted by Frans Janssen:
Hi Frank,
I do agree that your approach (or the thin client approach in general) does not violate any of the musts in the assignment. And that is why people pass using such an approach, so you'll probably be safe with your design.
However, I still feel that because the interface declares a lock method, that should be taken as a hint that this method should be exposed over the network. Otherwise you could implement it as an empty method and that is probably not how the person that defined the interface meant it to be.
When I started the assignment, my first hunch too was to make a thin client, but I changed my mind when I realized that I then would have no purpose for the lock method.
Frans.
Use of functionality provided by the core Java classes will be prefereed to your own implementation of that functionality
A clear design, such as will be readily understood by junior programmers, will be preferred to a complex one
----------------<br />SCJP (98%)<br />SCJD (81%)<br />SCEA (near future)
Originally posted by Ryan Tang:
For update, first I check if the record is being locked by the specified cookie within the HashMap sync block. Then I perform the actual I/O update out of the sync block.
For delete, I do similarly as update, but include another HashMap sync block after delete to remove the locked record.
For lock, I perform the checking "is record already locked" and "does record exist" in the HashMap sync block, and wait if the record is already locked. Cookie is returned if lock is placed. It is the simpliest design.
For unlock, I perform record existence checking out of the HashMap sync block. I check if record is locked by the specified cookie and remove the locked record entry in the sync block.
----------------<br />SCJP (98%)<br />SCJD (81%)<br />SCEA (near future)
Originally posted by Frank Verbruggen:
I think they want u to make the desicion that the lock and unlock should be implemented using smart synchronization, whihch is something my approach readily takes care of.
What do u think
SCJP 1.4, SCJD
I'm so happy! And I wish to make this tiny ad happy too:
New web page for Paul's Rocket Mass Heaters movies
https://coderanch.com/t/785239/web-page-Paul-Rocket-Mass
|