This week's book giveaway is in the Artificial Intelligence forum.
We're giving away four copies of Pragmatic AI and have Noah Gift on-line!
See this thread for details.
Win a copy of Pragmatic AI this week in the Artificial Intelligence forum!

Glenn Jones

+ Follow
since Jul 03, 2003
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Glenn Jones

Thanks to those who answered my DuplicateKeyException question, your advice has been most helpful. I have an RMI question that I hope you can help with. Although this is a general question there is a specific issue for URLyBird as well. Section 3.2 of the RMI specification states that:
"A method dispatched by the RMI runtime to a remote object implementation may or may not execute in a separate thread. The RMI runtime makes no guarantees with respect to mapping remote object invocations to threads. Since remote method invocation on the same remote object may execute concurrently, a remote object implementation needs to make sure its implementation is thread-safe."
It seems to me that there are more serious implications to this characteristic of RMI than the specification suggests. In addition to stating that an implementation must make sure it is thread safe it should also state that an implementation must make sure it is multithreaded if it contains any synchronized code. If all server methods are run on a single thread and that thread is blocked in a method that is waiting for some condition to change then does that mean that no other methods can be invoked on the server? If so, then it will be impossible for any methods to be invoked remotely and do anything that may change the condition that is blocking the method that holds the object lock.
The ambiguity about whether or not a method dispatched to the server will run in a separate thread present a problem for URLyBird. If it is the case that all server methods are invoked on the same thread then I must implement a multi-threaded server, probably on a thread per client basis. However, this would add a considerable amount of complexity to the code and testing has shown that it is unnecessary. My tests suggest that the implementation of RMI that I tested against creates multiple threads on the server, but is it safe to assume that all RMI implementations will do the same? The question is this:
Is it the case that a remote object implementation with synchronized methods must implement some form of multi-threading just in case the RMI runtime invokes all remote methods on the same thread?
Any help will be much appreciated.
Please can someone help me out with this problem. My assignment instructions specify that DBAccess#createRecord(String[]) must throw DuplicateKeyException, but it does not specify the conditions under which it should be thrown. The name of the exception suggests that it should be thrown when a client attempts to create a new record that has an identical "key" to an existing record. Assuming that some combination of the record fields constitutes the key, the exception should be thrown when an attempt is made to create a new record for which those fields are identical to an existing record. This seems reasonable, but I have to decide which combination of fields represent the key. Intuition suggests that a hotel room is uniquely identified by the combination of hotel name, city and room number. The problem is that room number is not included in the URLyBird database, which seems like a serious flaw in the database design. It is hard to understand how URLyBird can sell hotel rooms without being able to tell the customer the number of the room, and I can only assume that this is a deliberate mistake. With the current fields it is quite reasonable for two records to have identical fields but still represent different rooms, most hotels will have more than one room that is identical in those terms. For this reason I have chosen never to throw this exception, and I have questioned whether room number is missing from the schema design. Have I missed something obvious or is this a reasonable approach?