Using Unreferenced vs a daemon thread

[Peter den Haan]

Originally posted by HS Thomas:
I accept implementing WeakHashMap is infinitely less complex.

But is it? Read points 1, 3, 4 and 5 in my posting above.
- Peter

[John Smith]

I accept implementing WeakHashMap is infinitely less complex.

I would argue the opposite. Suppose you are a junior programmer, and you see code like this (this is Max's code that I changed a bit for the purposes of this demonstration):

public class HashMapDemo {
    public static void main(String[] args) {
        WeakHashMap weakMap = new WeakHashMap();
        String key = "myKey";
        weakMap.put(key, "myValue");
        System.out.println("before calling the garbage collector");
        System.out.println(weakMap);
        key = null;
        for (int i = 0; i < 100; i++){
            System.gc();
        }
        System.out.println("after calling the garbage collector");
        System.out.println(weakMap);
    }
}

What do you think is the output? Even if you are a senior developer, you would bet $100 that the "myValue" entry would be dereferenced after the key was set to null, right? Wrong answer! You can run gc 10,000 times and let VM run for 5 years, but the "myValue" entry will still be in the map. The little dirty trick that I played here was using the String literal as a key. Since that object is controlled by VM itself, it will never be dereferenced! Granted, in this assignment, you are not likely to use a string as a key, but what it demonstrates is that WeakHashMap is not as straightworward as you might think. You also need to be extra carefull with recreatable key objects.
All of the above aside, the main argument against the WeakHashmap is that it is an artificial construct in the context of RMI garbage collection, as opposed to a natural API for Unreferenced. If I were to weigh the pros and cons of the WeaksHashMap vs Unreferenced, I would assign a very heavy weight to the "How natural?" criteria.
Eugene.
[ March 20, 2003: Message edited by: Eugene Kononov ]

[HS Thomas]

For dudes/dolls like me trying to get a handle on this debate.

|Mission  |                                                                                                
|critical |                                                                                                
|weighting|                                                     |  Unreferenced      |    WeakHashMap     |
|   2     |   A client connection can lock multiple             |          X         |                    |
|         |    records                                          |                    |                    |
|   2     |   A client connection can lock records              |          X         |         X          |
|         |    singly                                           |                    |                    |
|   3     |   Will always be dereferenced                       |          X         |                    |
|   3     |   Allows for unreferencing of remote objects safely |          X         |         X          |
|   3     |   No performance overhead                           |          X         |         X          |
|   2     |   Easy to understand,code,maintain                  |n.b. 1    X         | n.b.2   X          |
|   1     |   No complexity                                     |                    |                    |
|   3     |   Code expressive of the problem hence reusable with|          X         |                    |
|         |     no or little change                             |                    |                    |
|   3     |   Use of API standard to the task                   |          X         |                    |
                                                          _________________________________________________ 
                                  Score by weighting                      21                  10           
n.b.
----
 1 : A programmer needs to understand synchronisation on when to Unreference with waiting for locks.
     For a programmer working at this cert level this is a must. 
     Client - record locking is not a task for a junior programmer. The requirements may change to 
     allow multiple record licking 
 
 2 : A programmer only needs to understand how to use and traverse the WeakHashMap

regards
[ March 20, 2003: Message edited by: HS Thomas ]

[HS Thomas]

Max ,

but what it demonstrates is that WeakHashMap is not as straightworward as you might think.

This assertion and the ones Peter made does throw the X against WeakHashMap for "Will always be dereferenced" off the chart.
I was wondering whether in the context of the assignment it will be allowable?
Sorry, that comment was prompted by fear of the unknown.
If I understood all RMI was doing/meant to do , I'd certainly go to the lengths below to ensure
that I am replacing like functionality for like.
As I am unlikely to cover all that material, I'd
certainly opt then for using a standard API.

1. Rejig your design to employ a counterintuitive mapping of clients to locks rather than, as the problem dictates, the other way around; ensure that your code enforces the one-owner-only nature of the locks that the data structure now no longer enforces.
2. Document in your design decisions why the resultant restrictions in the lock() API were a good tradeoff. Please note that the Data javadoc implies no restrictions whatsoever on the number of records locked.
3. Dig in the spec and API to understand how WeakHashMap works and how it affects your design. The difference between soft, weak and phantom references, anyone? Don't forget to go through the RMI specification to ensure that you are guaranteed that RMI releases all references to your object. After all, you cannot rely on the behaviour of the particular RMI implementation you happen to be using.
4. Carefully go over your code to ensure that the fact that WeakHashMap doesn't obey the usual Map invariants doesn't affect your code. For example, a call to map.containsKey(client) can return true yet a subsequent call to map.get(client) return null, even inside a synchronized block. This kind of odd behaviour may not affect you, but are you sure without fully understanding how WeakHashMap works and carefully inspecting your code? WeakHashMap is most emphatically not a simple, devoid-of-complexity drop-in replacement for HashMap as suggested.
5. Find a way make sure that locks are actually cleaned up timely and notifyAll() gets called so a freed lock can actually find a new owner within a predictable, bounded time. I haven't seen any answer to this yet.

I am happy to update the chart again for any strong comeback.Remember, test supported cases score extra points.
regards
[ March 20, 2003: Message edited by: HS Thomas ]

[Max Habibi]

And looking at the properties and constraints of the problem (funcionality, mathematical, performance, whatever slant you take on it), a WeakHashMap forces you to map exactly the wrong way around. It makes the code much less expressive of the problem, and introduces performance penalties arbitrary constraints in the process, without justification (in my eyes) in simplicity, functionality, or performance. I've already beaten this subject to death; I won't repeat that here.

And I think I've beaten the refutation of the above to death, so I won't bother do so again . However, I will say that simply invoking Mathematics, performance, etc., then making a statement them does not construes an argument. The only thing that ever came out those arguments was ...well, never mind. Lets agree to take that up at another time.

quote:
--------------------------------------------------------------------------------
In the airline industry, in which I have actually worked, there are usually business rules that disallow a Client Rep from booking more then a single flight at a time
--------------------------------------------------------------------------------
I believe it is an absolute mistake to look at the database as a flights database.

I'm starting to understand that this is your respective, and it may explain your position. However, it is not an absolute mistake, as Sun's design specs specifically state that you may choose to modify the Data class. They also say that you may choose to extend it. [b][i]nowhere do they say that you need to make it generic: thus, it naturally follows that is not an absolute mistake. Your statement stand unsupported, thus, any conclusions reached from the inviolate 'nature' of the Data class must be discarded.

The Data class you've been given makes this clear in no uncertain terms. Whoever wrote it went the extra (air) mile or two to make it absolutely, completely generic with zero, zip, zilch FBN dependence or FBN-specific assumptions. This is the class we are being asked to modify and enhance.
quote:
--------------------------------------------------------------------------------
There are absolutely no significant performance overheads, since we're talking about millisecond here, and in some cases, hashmaps are actually faster then treemaps
--------------------------------------------------------------------------------
They obviously are faster, as hashing gives you O(1) performance on most things where trees give you O(log N) performance. But we aren't comparing HashMaps to TreeMaps. We're comparing HashMaps to WeakHashMaps; AFAIK both have the same big-O behavior. WeakHashMaps are slower but, as you note, it does not really matter much -- we've not been asked to develop for performance -- it's just another very small and minor exhibit in the case against a WeakHashMap.

It's not even a minor issue. It's a minor, minor, minor issue . And since it is so minor, I'm sure that you have better arguments?

You're suggesting complexity where there isn't any.

I'm making the point, as you are below, the there is more complexity that has to be waded through before you can 'safely' use this feature.

that is, be notified of the loss of the client's reference. As you say, "The unrefernced interface is a standard solution if you need to remote object to do something before it exits.". : we want the remote object to

Yes, but there are more elegant ways of doing this then hand writing specific code for it. It's always best to have object cleaned up automatically if possible. Your suggestion ignores this.

-- well, that's exactly what we want to do: we want the remote object to clean up its locks. I think you generally will have to come up with very compelling reasons indeed to ignore standard API in favor of your own thing.

Not I, but you need to come up for a very compelling reason for ignoring the standard API. You want to ignore a standard object from the java.util package, in favor of a standard object from the java.rmi package. Since RMI implies more complexity then java.lang., then burden of proof lies with you, I would think.

Note that the requirements explicitly state that you should use standard API wherever possible.

It is my guiding light.

You do of course say that WeakHashMap is also standard API. Which it is, but not for this task.

I wasn't aware that parts of the java API were being ruled out for this task: was that in the documentation? . But seriously, of course it's standard API. The fact that you acknowledge this doesn't mean that it can be dismissed.

quote:
--------------------------------------------------------------------------------
Actually, in a remote system, just as in a local system, it's best to automatically delete objects that don't have a reference. If you can get that for free by using a WeakHashmap, in addition to releasing the locks those objects hold, then using Unreferenced seems, to me, not to be the most elegant solution.
--------------------------------------------------------------------------------

If you can get it for free, yes

And you can get it for free.

... but not at the expense of expressivity of the problem domain, arbitrary restrictions on server functionality,

Let's be clear: these restrictions are no more arbitrary then providing 'features' that the user didn't ask for, like multiple locks per client.

use of non-standard API,

This is just nonsense, The java.util.* package is a part of the standard API, as you yourself have attested on numerous occasions.

conceptual complexity,

Which is why I'm avoid the more complex solution.

cleanup predictability (gc involved), l

There is always clean up unpredictability, and the gc is always involved when you're working with RemoteObjects.

lock availability after cleanup (no notifyAll!),

You'll have to be more clear here.

and performance.

again, an explicit non issue, per the requirements. Also, it's never been established the performance is an issue with WeakHashMaps, though we have discussed it in the past. And before we go off on this tangent, lets stay on topic and focus the discussion. We can always address this later.

But all of the below instead:
1. Rejig your design to employ a counterintuitive mapping of clients to locks rather than, as the problem dictates, the other way around;

again, the problem never states this, nor does it 'dictate' it. The fact that you say that it does simply does not change that.

ensure that your code enforces the one-owner-only nature of the locks that the data structure now no longer enforces.

when the user provides no preference, then the developer has the responsibility to write the simplest implantation possible. IMO, yours is not that, for the reasons given above.

2. Document in your design decisions why the resultant restrictions in the lock() API were a good tradeoff. Please note that the Data javadoc implies no restrictions whatsoever on the number of records locked.

True. Thus, it's perfectly reasonable for a developer to provide the simplest solution, given this lack of restrictiveness.

3. Dig in the spec and API to understand how WeakHashMap works and how it affects your design.

Yes, you do need to understand how collections work .

The difference between soft, weak and phantom references, anyone?

versus all of the myriad of issues that can arise from Unreference? I'll take the standard API stuff, thanks . I still haven't seen a fully implements solution for the UnReferenced material.

Don't forget to go through the RMI specification to ensure that you are guaranteed that RMI releases all references to your object. After all, you cannot rely on the behavior of the particular RMI implementation you happen to be using.

Non sequitur, since you have to understand RMI regardless. The question is, are you also going to have to dig into the complexities of Unreferenced? Not in the design that I'm advocating.

4. Carefully go over your code to ensure that the fact that WeakHashMap doesn't obey the usual Map invariants doesn't affect your code.

Yes, you will have to understand the WeakHashMap in order to use them. Personally, I think they are worth the investment.

For example, a call to map.containsKey(client) can return true yet a subsequent call to map.get(client) return null, even inside a synchronized block.

Yes, this is a class example, and a well known one. However, has no bearing on this solution, as I think you know.

This kind of odd behavior may not affect you, but are you sure without fully understanding how WeakHashMap works and carefully inspecting your code?
WeakHashMap is most emphatically not a simple, devoid-of-complexity drop-in replacement for HashMap as suggested.

I think we're agreed that you would have to know how WeakHapMaps work before you used them.

5. Find a way make sure that locks are actually cleaned up timely

This is not guaranteed with either approach: like the gc, the JVM will simply decide when to call Unreferenced on a Remote object. But I'm sure you know this.

and notifyAll() gets called so a freed lock can actually find a new owner within a predictable, bounded time. I haven't seen any answer to this yet.

And I haven't seen this question articulated yet. Can you provide some context? Can you demonstrate a example where such a problem exists with a WeakHashMap?
M

[Max Habibi]

Originally posted by Eugene Kononov:
What do you think is the output? Even if you are a senior developer, you would bet $100 that the "myValue" entry would be dereferenced after the key was set to null, right?

Any senior developer that worked for me that said so would lose a lot then a $100 dollars . Seriously, it's well known, I would think, to a senior developer, that Strings don't interact with the gc() the same way that other objects do. However, this is a non sequitur , since we're not really talking about using String as keys.

main argument against the WeakHashmap is that it is an artificial construct in the context of RMI garbage collection, as opposed to a natural API for Unreferenced. If I were to weigh the pros and cons of the WeaksHashMap vs Unreferenced, I would assign a very heavy weight to the "How natural?" criteria.

The WeakHashMap cannot be an artificial construct in Java, since it's part of the standard Java API. As a matter of fact, using unrefernced in the way that you're talking about takes on a great deal of 'unnaturalness', assuming we can define the term, and that we can agree that it's part of the criteria of the exam, because you have to deal with the awkward possibility the object will be garbage collected out from under you even as you're trying to invoke the Unreferenced method on it.
M

[HS Thomas]

Agreeing to disagree, with several degrees of separation.
Some of this is very subjective to perspective of the problem statement. And even that is often not fixed, in reality.

|Mission  |                                                                                                
|critical |                                                                                                
|weighting|                                                     |  Unreferenced      |    WeakHashMap     |
|   2     |   A client connection can lock multiple             |          X         |                    |
|         |    records                                          |                    |                    |
|   2     |   A client connection can lock records              |          X         |         X          |
|         |    singly                                           |                    |                    |
|   3     |   Will always be dereferenced                       |          X         | [3]     X          |
|   3     |   Allows for unreferencing of remote objects safely |          X         |         X          |
|   3     |   No performance overhead                           |          X         |         X          |
|   2     |   Easy to understand,code,maintain                  |[1]       X         | [2]     X          |
|   1     |   No complexity                                     |                    |                    |
|   3     |   Code expressive of recurring problem ; reusable   |          X         |                    |
|         |     with no or little change                        |                    |                    |
|   3     |   Use of API standard to the task -                 |          X         |         X          |
|         |     standard is subjective to the approach taken    |                    |                    |  
                                                          _________________________________________________ 
                                  Score by weighting                      21                  16           
n.b.
----
 [1] : A programmer needs to understand synchronisation on when to Unreference with waiting for locks.
     For a programmer working at this cert level this is a must. 
     Client - record locking is not a task for a junior programmer. The requirements may change to 
     allow multiple record locking 
 
 [2] : A programmer only needs to understand how to use and traverse the WeakHashMap
 [3] : With the exception of String key objects which are not GC'd in the normal way

regards
[ March 20, 2003: Message edited by: HS Thomas ]

[Max Habibi]

This assertion and the ones Peter made does throw the X against WeakHashMap for "Will always be dereferenced" off the chart.

While it's true that assertions like the above can be troubling, there is no need to fear. The WeakhashMap entries, and the unreferenced calls, are both equally likely to work and/or to fail. That is, they are both @ whim of the jvm.
M

I was wondering whether in the context of the assignment it will be allowable?

Not only allowable, but I can guarantee that it's possible to earn a perfect score with it.
The Unreferenced solution is not a bad one: it's simply more complex then it needs to be, IMO. Since complexity is strictly warned against in the assignment, avoiding it rates pretty highly with me.
Correspondingly, since allowing a single client to lock multiple records is not required at all by the assignment, it ranks pretty low for me. I certainly wouldn't consider it mission critical. Thus, I might assign a .5 weight to the locking multiple locks to multiple clients issue, and probably a 3 or a 4 to the complexity and maintainability issue. That is, the WeakHashMap solution does not require any complex coding(or any @ all, just change your data structure). Thus, it's a true 'freebie'.
With the unrefernced, you have to defend your design by saying: "look, I know this is more complex code, but it keeps lost records from killing the application". The assessor might decide that the added complexity is worthwhile in terms of performance(in this case, I mean overall system friendliness, not resource usage). However, they might decide that it is not. Thus, you might actually end up getting docked points for going the extra mile!
This is consistent with the advice of other authors on this topic: that is, trying to do 'too much', and getting nailed for it. In this case, dealing with lost records is going above and beyond. Fine: however, per the directions, this is only justified if you can do so with the absolute bare mimimal complexity. Have you done so?
One last thing. I would disagree that writing no unreferencing code is the equal to writing that code,Of course . Thus, I wouldn't rate both solutions equally complex. However, that's just my opinion, and I think that Peters is also valid and reasonable. We are both capable of logic, we simply give different weight to different merits.
All best,
M
[ March 20, 2003: Message edited by: Max Habibi ]

[HS Thomas]

]

Thus, I might assign a .5 weight to the locking multiple locks to multiple clients issue, and probably a 3 or a 4 to the complexity and maintainability issue. That is, the WeakHashMap solution does not require any complex coding(or any @ all, just change your data structure).

|Mission  |                                                                                                
|critical |                                                                                                
|weighting|                                                     |  Unreferenced      |    WeakHashMap     |
|   1     |   A client connection can lock multiple             |          X         |                    |
|         |    records                                          |                    |                    |
|   2     |   A client connection can lock records              |          X         |         X          |
|         |    singly                                           |                    |                    |
|   3     |   Will always be dereferenced                       |          X         | [3]     X          |
|   3     |   Allows for unreferencing of remote objects safely |          X         |         X          |
|   3     |   No performance overhead                           |          X         |         X          |
|   4     |   Easy to understand,code,maintain                  |[1]       X         | [2]     X          |
|   3     |   No complexity                                     |                    |                    |
|   3     |   Code expressive of recurring problem ; reusable   |          X         |                    |
|         |     with no or little change                        |                    |                    |
|   3     |   Use of API standard to the task -                 |          X         |         X          |
|         |     standard is subjective to the approach taken    |                    |                    |  
                                                          _________________________________________________ 
                                  Score by weighting                      22                  18           
n.b.
----
 [1] : A programmer needs to understand synchronisation on when to Unreference with waiting for locks.
     For a programmer working at this cert level this is a must. 
     Client - record locking is not a task for a junior programmer. The requirements may change to 
     allow multiple record locking 
 
 [2] : A programmer only needs to understand how to use and traverse the WeakHashMap
 [3] : With the exception of String key objects which are not GC'd in the normal way

regards
[ March 20, 2003: Message edited by: HS Thomas
[ March 20, 2003: Message edited by: HS Thomas ]

[Max Habibi]

HS,
Nice job of gathering the points for this discussion. While it's true that I still feel that the added complexity weights should be different(Writing no code beats writing code hands down to me)), I think you've been honest and fair is expressing your opinion, and added a lot of value by keeping score.
One little nitpick. If value of client/record == 1, then the value of record/client should also equal one. I am not contending that one solution is better then the other, just that they are equal.
All best,
M

[Mark Spritzler]

Picture of Mark in the stands

          __________________________
    ^     \           U            /
   ( )     \          N           /
    -      /\         R          /
    |     /  \        E         /
  /---\  /    \       F        /
 / | | \/      \      E       /
 | | |          \     R      /
 | | |           \    E     /
 ^ ---            \   N    /
   / \             \  C   /   
  /   \             \ E  /
  |   |              \D /
  |   |               \/
  |   |
  ^   ^

Yes I know, it is that big.
Mark
[ March 20, 2003: Message edited by: Mark Spritzler ]

[John Smith]

Originally posted by Mark Spritzler:
Picture of Mark in the stands

          __________________________
    ^     \           U            /
   ( )     \          N           /
    -      /\         R          /
    |     /  \        E         /
  /---\  /    \       F        /
 / | | \/      \      E       /
 | | |          \     R      /
 | | |           \    E     /
 ^ ---            \   N    /
   / \             \  C   /   
  /   \             \ E  /
  |   |              \D /
  |   |               \/
  |   |
  ^   ^

Hey Thomas, add 5 points to Unreferenced for this.
Eugene.

[HS Thomas]

Max,
Thanks. I am glad you thought it was useful.
I've made a few adjustments.
I think I have been fair as if you apply assignment weightings both Unreferenced and WeakHashMap score equally.
In my view , Unreferenced prepares a developer to gaining a bigger picture. But it is harder work as it's more complex - but hopefully the benefits will follow .
Mark,
isn't that flag the wrong way down ?
Eugene,
I think I have already appointed Unreferenced the points it deserves.

Peter,
Have I missed anything that is glaringly lacking in the chart ?
Forget the weightings , each one can adjust it to their own environmental influences.

|Mission  |                                                                                                
|critical |                                                                                                
|weighting|                                                     |  Unreferenced      |    WeakHashMap     |
|   2     |   A client connection can lock multiple             |          X         |                    |
|         |    records                                          |                    |                    |
|   2     |   A client connection can lock records              |          X         |         X          |
|         |    singly                                           |                    |                    |
|   3     |   locks will always be dereferenced                 |          X         | [3]     X          |
|   3     |   Allows for unreferencing of remote objects safely |          X         |         X          |
|   3     |   No performance overhead                           |          X         |         X          |
|   4     |   Easy to understand,code,maintain                  |[1]       X         | [2]     X          |
|   3     |   No complexity                                 [5] |                    |                    |
|   3     |   Code expressive of recurring problem , reusable   |          X         |                    |
|         |     with no or little change                    [4] |                    |                    |
|   3     |   Use of API standard to the task -                 |          X         |         X          |
|         |     standard is subjective to the approach taken[4] |                    |                    |  
                                                          _________________________________________________ 
                                  Score by weighting                      23                  18           
n.b.
----
 [1] : A programmer needs to understand synchronisation on when to Unreference with waiting for locks.
     For a programmer working at this cert level this is a must. 
     Client - record locking is not a task for a junior programmer. The requirements may change to 
     allow multiple record locking 
 
 [2] : A programmer only needs to understand how to use and traverse the WeakHashMap
 [3] : With the exception of String key objects which are not GC'd in the normal way
 [4] : Your approach could be guided by factors like waiting for a decision to support a fully-fledged distributed system
       - ( Use WeakHashMap in the interim ) or they want a fully-fledged distributed system. (use Unreferenced)
 
       Code expressive of recurring problem , reusable with no or little change , is already capable of supporting 
       at least one fully-fledged distributed system (RMI) and could be used to support others(JNDI,Javaspaces-
       do they use Unreferenced ? )
       Changing or layering on top of a WeakHashMap to support distributed system functionality is not to be recommended.
       So, programmer you have been warned.     
 [5] : Both WeakHashMap and Unreferenced have hidden complexities. The developer needs to be aware of them to make informed
       design choices. 

regards
[ March 21, 2003: Message edited by: HS Thomas ]

[Peter den Haan]

Originally posted by Max Habibi:
However, I will say that simply invoking Mathematics, performance, etc., then making a statement them does not construes an argument.

This is so far off the mark that I hardly know where to start. I've shown that the problem is a natural fit for a Map in one direction only. Your assertion that it was a non sequitur has never become anything more than that, an unsubstantiated assertion. I've done my bit and went to the extent of using a mathematical argument. Now do your bit. Show me the gap. Show me where I miss the mark. Demonstrate. Don't just assert. Repeat it for my sake. Or link me the thread.

[...] Sun's design specs specifically state that you may choose to modify the Data class. They also say that you may choose to extend it. nowhere do they say that you need to make it generic: thus, it naturally follows that is not an absolute mistake.

Of course it doesn't say that you need to make it generic, because it bloody well already is fully generic! Are you trying to argue that that fact is wholly irrelevant? A coincidence? A matter not to be considered at all when contemplating modifications to and extension of that class? If so, you have a very strange approach to software development indeed.

Not I, but you need to come up for a very compelling reason for ignoring the standard API. You want to ignore a standard object from the java.util package, in favor of a standard object from the java.rmi package.

That's a bit too easy and rather meaningless. Your position, taken to its logical conclusion, means that all code one could possibly write satisfies Sun's requirement that "the design should use standard Java package facilities wherever possible" because all code ultimately uses java.lang.* and so forth. That is of course not what it means. What it means is that, given a task, if there is a standard API to accomplish that task, you should use it. The standard API for doing something when all references to a Remote object get lost is Unreferenced. Fact. You're ignoring this in favour of your own solution which involves garbage collector action on Remote objects. Fact.

There is always clean up unpredictability, and the gc is always involved when you're working with RemoteObjects.

There is no gc involved in Unreferenced when a client crashes. Just the RMI DGC, and its action (in contrast to the JVM gc) is fully predictable here.

lock availability after cleanup (no notifyAll!),
You'll have to be more clear here.

After a client has been removed from the WeakHashMap, who is calling notifyAll() so that another client that may be waiting for the lock gets woken up? If my mental image of your code is correct, it doesn't happen. You have to wait an indefinite amount of time until a totally unrelated unlock event happens. If you happen to be working late and there's nobody else around, tough, you'll be around 'till the morning.

again, [performance is] an explicit non issue, per the requirements. Also, it's never been established the performance is an issue with WeakHashMaps, though we have discussed it in the past.

I wasn't referring to WeakHashMap performance, but to the performance penalty you pay for having the Map the wrong way around (lock() has O(N) performance rather than O(1)). No, performance is not a primary design goal, and not the most important part of the price to pay.

Dig in the spec and API to understand how WeakHashMap works and how it affects your design.
Yes, you do need to understand how collections work

Another glib comeback. Very good. WeakHashMap is not just another Map and you know it.

Non sequitur, since you have to understand RMI regardless. The question is, are you also going to have to dig into the complexities of Unreferenced? Not in the design that I'm advocating.

If you have to understand how RMI works regardless, then you know how Unreferenced works, don't you? Because it's part and parcel of the RMI cleanup process that your WeakHashMap solution also relies upon, and (once you understand RMI DGC) a very straightforward part at that. Sequitur.

[Timely cleanup] is not guaranteed with either approach: like the gc, the JVM will simply decide when to call Unreferenced on a Remote object. But I'm sure you know this.

No, I don't know this. The RMI DGC does not operate like the JVM garbage collector at all, and comes with more guarantees. Specifically, when a client crashes you are guaranteed to be notified when the DGC lease expires (assuming no other references remain). A WeakHashMap-based solution piles the server-side gc on top of the DGC action, and adds its unpredictability to it.
- Peter
[ March 21, 2003: Message edited by: Peter den Haan ]

[Peter den Haan]

Originally posted by HS Thomas:
Have I missed anything that is glaringly lacking in the chart ?

Yes; a "data structures expressive of problem domain" item. This is a vital attribute of good design, and to my mind, an attribute that is sadly lacking if you have the Map the wrong way around.
As remarked on before, this subject has been beaten to death and we look set to flog the corpse some more.
If I'd have to express it as succinctly as possible, I'd say that the locks you're trying to dole out have two defining attributes. The first and most important is the constraint that each record lock can be given to one client and one client only. It follows that the collection of locked records is a Set. The second, less important, one is that there is no a priori reason why a client cannot own multiple locks; the collection of lock owners is a Collection where a client may occur more than one time. So in the problem domain we have a relation between a Set and a Collection. If you want to use a Map to model that domain, it will fit only one way around, because a Map maps a key Set to a value Collection.
Invert the map, and your code becomes significantly less expressive and more error-prone (since the data structure no longer protects you from handing out locks more than once), you introduce a one-lock-only constraint, performance decreases, you pay the price in a number of ways. And for what reason? Cleanup aside, your code doesn't become simpler, to the contrary! And as far as cleanup is concerned, well, opinions differ on whether things become simpler or not, but the ability to use WeakHashMap alone can never be a reason to compromise your design like that.
The second thing I'm missing from the list is that, as far as I understand the code Max is talking about, the WeakHashMap solution implements cleanup only imperfectly since waiting clients aren't notifyAll()ed that the now-freed-up lock is available. This, plus the dependence on the action of the server-side garbage collector, adds a lot of unpredictability to the cleanup action.
- Peter
[ March 21, 2003: Message edited by: Peter den Haan ]

[HS Thomas]

Peter,
I thought the following

Code expressive of recurring problem , reusable with no or little change

covered

"data structures expressive of problem domain"

but I guess you have to confidently be able to replace one collection type with another , is what you are saying.
I will address it in a mo - just needs some digestion.
regards
[ March 21, 2003: Message edited by: HS Thomas ]

[Peter den Haan]

Originally posted by HS Thomas:
I thought "code expressive of recurring problem [...]" covered "data structures expressive of problem domain"

Maybe it does; the interpretation of this criterion is up to you. In that case I'd argue that its weighting is way too low. Finding a good mapping from problem domain to object (or data) model is the cornerstone of good design.
Are you sure you don't regret acting referee in what must be one of the most long-running and... erm... enthusiastically conducted technical disputes in this group?
- Peter
[ March 21, 2003: Message edited by: Peter den Haan ]

[Mark Spritzler]

Yes my banner is upside down, but with the characters available on the keyboard, that was the only direction I could use.
Mark

[HS Thomas]

enthusiastically conducted

. Who, me?
I wish I could claim that much technical knowledge. This is purely a learning process. If you both are going to drag us down into the bowels of Unreferenced and WeakHashMap, all the better.
I'll be there, cheap scoring point for point.
Just joking .
On a serious note :
I think that " Code expressive of recurring problem , reusable with no or little change" covers the requirement of the problem domain to support the distributed release of locks - the keyword being distributed.i.e. RMI can be replaced by another distributed API with it's own
more effective release mechanism.
" Data structure expressive of the problem domain " covers the requirement of the problem domain to support the release of multiple locks.
The data structure has to be able to hold Client-key and locks-Set values?
I think it's already covered in " A client connection can lock multiple records" in apprentice terms. I have added layman terms in brackets against that in layman terms. Hope that's agreeable.

|Mission  |                                                                                                
|critical |                                                                                                
|weighting|                                                     |  Unreferenced      |    WeakHashMap     |
|   2     |   A client connection can lock multiple records     |          X         |                    |
|         |   ( data structures expressive of problem domain)   |                    |                    |                    |
|   2     |   A client connection can lock records              |          X         |         X          |
|         |    singly                                           |                    |                    |
|   3     |   locks will always be dereferenced                 |          X         | [3]     X          |
|   3     |   Allows for unreferencing of remote objects safely |          X         |         X          |
|   3     |   No performance overhead                           |          X         |         X          |
|   4     |   Easy to understand,code,maintain                  |[1]       X         | [2]     X          |
|   3     |   No complexity                                 [5] |                    |                    |
|   3     |   Code expressive of recurring problem , reusable   |          X         |                    |
|         |     with no or little change                    [4] |                    |                    |
|   3     |   Use of API standard to the task -                 |          X         |         X          |
|         |     standard is subjective to the approach taken[4] |                    |                    |  
                                                          _________________________________________________ 
                                  Score by weighting                      23                  18           
n.b.
----
 [1] : A programmer needs to understand synchronisation on when to Unreference with waiting for locks.
     For a programmer working at this cert level this is a must. 
     Client - record locking is not a task for a junior programmer. The requirements may change to 
     allow multiple record locking 
 
 [2] : A programmer only needs to understand how to use and traverse the WeakHashMap
 [3] : With the exception of String key objects which are not GC'd in the normal way
 [4] : Your approach could be guided by factors like waiting for a decision to support a fully-fledged distributed system
       - ( Use WeakHashMap in the interim ) or they want a fully-fledged distributed system. (use Unreferenced)
 
       Code expressive of recurring problem , reusable with no or little change , is already capable of supporting 
       at least one fully-fledged distributed system (RMI) and could be used to support others(JNDI,Javaspaces-
       do they use Unreferenced ? )
       Changing or layering on top of a WeakHashMap to support distributed system functionality is not to be recommended.
       So, programmer, you have been warned.     
 [5] : Both WeakHashMap and Unreferenced have hidden complexities. The developer needs to be aware of them to make informed
       design choices. 

[ March 21, 2003: Message edited by: HS Thomas ]
[ March 21, 2003: Message edited by: HS Thomas ]

[HS Thomas]

The second thing I'm missing from the list is that, as far as I understand the code Max is talking about, the WeakHashMap solution implements cleanup only imperfectly since waiting clients aren't notifyAll()ed that the now-freed-up lock is available. This, plus the dependence on the action of the server-side garbage collector, adds a lot of unpredictability to the cleanup action.
- Peter

and

quote:
--------------------------------------------------------------------------------
[Timely cleanup] is not guaranteed with either approach: like the gc, the JVM will simply decide when to call Unreferenced on a Remote object. But I'm sure you know this.
--------------------------------------------------------------------------------
No, I don't know this. The RMI DGC does not operate like the JVM garbage collector at all, and comes with more guarantees. Specifically, when a client crashes you are guaranteed to be notified when the DGC lease expires (assuming no other references remain). A WeakHashMap-based solution piles the server-side gc on top of the DGC action, and adds its unpredictability to it.
- Peter

Guaranteed (DGC) vs whimsical (Server-side GC)
Max, you did say it was whimsical(and we all know , it is) when you provided your test.
Peter , is the guranteedness of DGC testable or can you point us to a link ?
I think a distributed system will have a/ought to have a guaranteed means of notification otherwise who will buy into it ?
Guess what , I will put it onto the chart.
regards

|Mission  |                                                                                                
|critical |                                                                                                
|weighting|                                                     |  Unreferenced      |    WeakHashMap     |
|   2     |   A client connection can lock multiple records     |          X         |                    |
|         |   ( data structures expressive of problem domain)   |                    |                    |                    |
|   2     |   A client connection can lock records              |          X         |         X          |
|         |    singly                                           |                    |                    |
|   3     |   locks will always be dereferenced                 |          X         | [3]     X          |
|   3     |   Allows for unreferencing of remote objects safely |          X         |         X          |
|   3     |   No performance overhead                           |          X         |         X          |
|   4     |   Easy to understand,code,maintain                  |[1]       X         | [2]     X          |
|   3     |   No complexity                                 [5] |                    |                    |
|   3     |   Code expressive of recurring problem , reusable   |          X         |                    |
|         |     with no or little change                    [4] |                    |                    |
|   3     |   Use of API standard to the task -                 |          X         |         X          |
|         |     standard is subjective to the approach taken[4] |                    |                    |  
|   3     |   Utilises guaranteed means for lock clean-ups      |          X         |                    |
                                                          _________________________________________________ 
                                  Score by weighting                      26                  18           
n.b.
----
 [1] : A programmer needs to understand synchronisation on when to Unreference with waiting for locks.
     For a programmer working at this cert level this is a must. 
     Client - record locking is not a task for a junior programmer. The requirements may change to 
     allow multiple record locking 
 
 [2] : A programmer only needs to understand how to use and traverse the WeakHashMap
 [3] : With the exception of String key objects which are not GC'd in the normal way
 [4] : Your approach could be guided by factors like waiting for a decision to support a fully-fledged distributed system
       - ( Use WeakHashMap in the interim ) or they want a fully-fledged distributed system. (use Unreferenced)
 
       Code expressive of recurring problem , reusable with no or little change , is already capable of supporting 
       at least one fully-fledged distributed system (RMI) and could be used to support others(JNDI,Javaspaces-
       do they use Unreferenced ? )
       Changing or layering on top of a WeakHashMap to support distributed system functionality is not to be recommended.
       So, programmer you have been warned.     
 [5] : Both WeakHashMap and Unreferenced have hidden complexities. The developer needs to be aware of them to make informed
       design choices. 

[ March 21, 2003: Message edited by: HS Thomas ]

[HS Thomas]

Yes my banner is upside down, but with the characters available on the keyboard, that was the only direction I could use.
Mark

What kind of keyboard are you using ,Mark?
/\
/ \
/ \
/ \
/___ ____\ Impression of a tree -should have been a banner pointing the right way up.
[ March 21, 2003: Message edited by: HS Thomas ]
[ March 21, 2003: Message edited by: HS Thomas ]

[HS Thomas]

Correspondingly, since allowing a single client to lock multiple records is not required at all by the assignment, it ranks pretty low for me. I certainly wouldn't consider it mission critical. Thus, I might assign a .5 weight to the locking multiple locks to multiple clients issue, and probably a 3 or a 4 to the complexity and maintainability issue. That is, the WeakHashMap solution does not require any complex coding(or any @ all, just change your data structure). Thus, it's a true 'freebie'.
With the unrefernced, you have to defend your design by saying: "look, I know this is more complex code, but it keeps lost records from killing the application". The assessor might decide that the added complexity is worthwhile in terms of performance(in this case, I mean overall system friendliness, not resource usage). However, they might decide that it is not. Thus, you might actually end up getting docked points for going the extra mile!

I am not sure if you are suggesting here that you are likely to be penalised for using unreferenced just because it is more complex.
Personally , I think one ought to get extra points just for going that extra mile. Just think of the benefits/ broader horizons that opens up.

"look, I know this is more complex code, but it keeps lost records from killing the application".

I think you mean lost clients.
The added complexity is nothing when weighed against the benefits -
A client connection can lock multiple records ( data structures expressive of problem domain)
Utilises guaranteed means for lock clean-ups
Code expressive of recurring problem , reusable with no or little change , meaning if you were replacing RMI with another distributed system , chances are that it already supports Unreferenced.
It'll be easier getting Unreferenced supported as a standard means for locks cleanups than it would WeakHashMap,say, if you were appointed standards man in a rising Company. They may have used WeakHashMaps earlier when they were building prototypes.
Again, this is just my view.
regards
[ March 21, 2003: Message edited by: HS Thomas ]

[Mark Spritzler]

Originally posted by HS Thomas:

What kind of keyboard are you using ,Mark?

    /\
   /  \
  /    \ 
 /      \
/___ ____\  

Impression of a tree -should have been a banner pointing the right way up.
[ March 21, 2003: Message edited by: HS Thomas ]
[ March 21, 2003: Message edited by: HS Thomas ]

You need to put it in code tags.
And I am lyxdesic er dyslexic \/ or is that /\

Mark

[Max Habibi]

Originally posted by Max Habibi:
[QB]
I agree that this is a reasonable view, and it is your view. However, it's not the view of the graders. Most authors who focus on this issue agree on this. From Kathy's book,
"But we do know one thing: They(The Assessors) aren't looking to see how clever an algorithm designer you are! If anything, it's just the opposite. Instead, think team player. And don't even think about showing off your programming prowess by revising the specification to do something even better and cooler than what was asked for...".
I can only reaffirm that it's a very serious minus to the project that you're adding complexity, and, IMO, the chart should reflect this.
Add to that the fact that you're doing so(IMO) in a complex and heavy handed way, to provide functionality that is not required: I doubt it will do any benefit for your score, regardless of whether you and or I feel that it should(and btw, I agree with you: I wish the accessors would reconsider this policy). specificity, you're adding two items of complexity.
The first is the you're architecturing the project to support a locks of multiple records per client, which is not specified, not used, and thus not necessary. The second that you're adding significant complexity for the sake of releasing records held by lost clients.
In the design that I suggested, the second feature add is a freebie in terms of coding complexity, because you simple use one type of map instead of another. That's all. The first complexity mentioned, supporting multiple locks per client, is also not added in this design. Thus, there is no net add of complexity required (except that programmers know the java.util package),and you're adhearing to the design specs, and you're providing a cool feature(free of charge in terms of LOC, function Points, etc). Hence, my suggestion.

All best,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4

[John Smith]

"But we do know one thing: They(The Assessors) aren't looking to see how clever an algorithm designer you are!

Well, shouldn't this be a good argument against the WeakHashMap? I consider the WeakHashMap, not the Unreferenced, to be a clever idea to deal with garbage collection.

I can only reaffirm that it's a very serious minus to the project that you're adding complexity, and, IMO, the chart should reflect this.

Yes, absolutely. But again, for the reasons that I already listed in my previous post, I consider HashMap a more complex solution.
It seems that we are going in circles in this thread. The opposing sides presented their arguments and stand firm by them.
Eugene.

[Max Habibi]

------------------------------
"But we do know one thing: They(The Assessors) aren't looking to see how clever an algorithm designer you are!
-------------------------------------------------------------------------------
Well, shouldn't this be a good argument against the WeakHashMap?

Not at all, because a WeakHashMap isn't an algorithm: it's simply the appropriate data structure. The locking/unlocking algorithm remains the same, regardless of WeakHashMap or HashMap is used.

I consider the WeakHashMap, not the Unreferenced, to be a clever idea to deal with garbage collection.

Both are clever ideas, and both work. That is not the issue. The issue is, which is less complex? Remember, you're working for a client here, and they've told you what they want. Unreference, since it requires both comprehension of the API and implementation, is more 'expensive' then a WeakHashMap, which only requires comprehension of the API.

Yes, absolutely. But again, for the reasons that I already listed in my previous post, I consider HashMap a more complex solution.
It seems that we are going in circles in this thread. The opposing sides presented their arguments and stand firm by them.

Unfortunately, we were not able to convince each other this time: still, it's worthwhile to have these discussions.
All best,
M

[HS Thomas]

I have taken Max's comments into consideration and given WeakHashMap a score for Less complexity.
And also added a score for Unreference for going
"that extra mile" under "provides for future capabilities of the system by shortening the learning curve".
It's difficult to see how much further this can proceed / be resolved. I think there has been some agreement where issues have been weighed in the balance.Thanks, Max,Peter,Mark ,Eugene for letting me participate in the debate in this way.
Hope I haven't ruffled too many feathers or killed off some programmers souls by applying all those numbers to issues.
It has been useful to me to get a perspective of both sides - I would have firmly stuck to Unreferenced otherwise - The thing that was brought out the most for me was that big ain't necessarily better in the grand scheme of things.
If you had a team of developers with a multitude of skills but with no RMI/distributed computing knowledge you may NOT want them to pull them down this road if the business wasn't ready yet.Their skills may be better used elsewhere for the good of all -perhaps that is what the assessors mean by team player.

But if a business opportunity came along that required this knowledge, then the developers with this knowledge,would come in handy. Pity if you had no developers on hand to help.If I were a developer I would try to get this skill, just in case.There certainly will be more opportunities in time and the assessors may change the way they mark this criteria.
(But I think if you are already using RMI you ought to use Unreferenced )

But now I have to get stuck in and implement one or the other.
Thanks , the corpse has been given a good flogging once more. Im sure it will rise again.

|Mission  |                                                                                                
|critical |                                                                                                
|weighting|                                                     |  Unreferenced      |    WeakHashMap     |
|   2     |   A client connection can lock multiple records     |          X         |                    |
|         |   ( data structures expressive of problem domain)   |                    |                    |                    
|   2     |   A client connection can lock records              |          X         |         X          |
|         |    singly                                           |                    |                    |
|   3     |   locks will always be dereferenced                 |          X         | [3]     X          |
|   3     |   Allows for unreferencing of remote objects safely |          X         |         X          |
|   3     |   No performance overhead                           |          X         |         X          |
|   4     |   Easy to understand,code,maintain                  |[1]       X         | [2]     X          |
|   2     |   Less complexity                               [5] |                    |         X          |
|   3     |   Code expressive of recurring problem , reusable   |          X         |                    |
|         |     with no or little change                    [4] |                    |                    |
|   3     |   Use of API standard to the task -                 |          X         |         X          |
|         |     standard is subjective to the approach taken[4] |                    |                    |  
|   3     |   Utilises guaranteed means for lock clean-ups      |          X         |                    |
|   2     |   provides for future capabilities of the system by |          X         |                    |
|         |     shortening the learning curve                   |                    |                    |   
                                                          _________________________________________________ 
                                  Score by weighting                      28                  20           
n.b.
----
 [1] : A programmer needs to understand synchronisation on when to Unreference with waiting for locks.
     For a programmer working at this cert level this is a must. 
     Client - record locking is not a task for a junior programmer. The requirements may change to 
     allow multiple record locking 
 
 [2] : A programmer only needs to understand how to use and traverse the WeakHashMap
 [3] : With the exception of String key objects which are not GC'd in the normal way
 [4] : Your approach could be guided by factors like waiting for a decision to support a fully-fledged distributed system
       - ( Use WeakHashMap in the interim ) or they want a fully-fledged distributed system. (use Unreferenced)
 
       Code expressive of recurring problem , reusable with no or little change , is already capable of supporting 
       at least one fully-fledged distributed system (RMI) and could be used to support others(JNDI,Javaspaces-
       do they use Unreferenced ? )
       Changing or layering on top of a WeakHashMap to support distributed system functionality is not to be recommended.
       So, programmer you have been warned.     
 [5] : Both WeakHashMap and Unreferenced have hidden complexities. The developer needs to be aware of them to make informed
       design choices. 

[ March 22, 2003: Message edited by: HS Thomas ]

[Max Habibi]

HS, a few more thoughts

I have taken Max's comments into consideration and given WeakHashMap a score for Less complexity.

not only is it less complex to implement, it adhears strictly to the requirements. IMO, that's a big plus. That, IMO, should probably also be a category: adheers stricly to requirements.

and also added a score for Unreference for going
"that extra mile" under "provides for future capabilities of the system by shortening the learning curve".

It seems that the Unreferenced solution was already awarded extra points for "reusable with no or little change". This is not significantly different then "provides for future capabilities of the system". Are both awards justified? The combined score is 5 points, and neither is a explicit requirement. Whereas the total score for avoiding complexity,which is a explicit requirement, is(I think) only 2 points. Something seems off. Surely adhearing to a explicit requirement should weigh heavily? And since it's already been accepted that the WeakHashMap solution is the less complex solution, then we should adhear to that.
As for "shortening the learning curve", I have a concern there. You are, in fact, only displacing the learning curve from the java.util.* package to the java.rmi.* package. There is no shortening of the learning curve here, there is only displacement. It's a toss up on if Unrefernced solution shortens the learning curve more then the WeakHashMap solution: certainly Peter and I disagree on this. The score should probably be even here. However, in the Unreferenced solution, you are unduly complicating not only RMI layer, but also the threading layer. More on this later.
It seems that, in light of my own advice, and that of the other authors who have written about this assignment, there should be an award for 'interprets the requirements strictly'.

It's difficult to see how much further this can proceed / be resolved.

There are still relevant issues to be discussed, I think. Don't tell we we're boring you .

I think there has been some agreement where issues have been weighed in the balance.Thanks, Max,Peter,Mark ,Eugene for letting me participate in the debate in this way. Hope I haven't ruffled too many feathers..

Quite frankly, I think you're doing a service to the site. I think it's clear( and you have said so), that you are predisposed to the Unreferenced solution. However, I believe you've made a very strenuous effort to be as objective as possible. If only you didn't have a predisposition to the complexity camp .

If you had a team of developers with a multitude of skills but with no RMI/distributed computing knowledge you may NOT want them to pull them down this road if the business wasn't ready yet.Their skills may be better used elsewhere for the good of all -perhaps that is what the assessors mean by team player.

It's interesting that you say this. In Kent Beck's excellent book, 'extreme Programming explained', he actually talks about re factoring a strikingly similar scenario, where the xp approach encourages him to extract a multiple mapping scenario from a system, because even though it was existing system feature, it wasn't actually used.

I discover that near as I can tell, the fabulous feature of the system where a single transaction can have debits from several accounts and credits to several accounts simply isn't used. Each transaction comes from one account and goes into one account. Is it possible to simply the system as in figure 2?...I ask Massimo to come sit with me while I examine the system...every single one of them( the transactions) has a single debit and a single credit account

He goes on then to change the system, simply because the feature isn't being used: Even though he knows that it could be, at some future time. Assuming that you buy into the xp thing, the question here is, are the implementations of the scjd project that have a client locking multiple records actually using that feature? If so, how is that justified via the requirements? If not, then why add fat? It seems that there should be catagory to utilizes provided archictural features'.
The reason I'm against this sort of approach, in principle, is because it acknowledges no hard boundaries. It allows huge, sprawling systems that have thousands of features, most of which are never used. We've all seen this.
In principle, to me, it's like over-packing. I'd rather take a little less then take too much. Of course, not everyone agrees with this approach, and what constitutes 'over-packing' is open to debate. To me, it's defined by my itinerary.

But if a business opportunity came along that required this knowledge, then the developers with this knowledge ,would come in handy. Pity if you had no developers on hand to help.

Not using a feature is not the same thing as not being able to understand it. I'll provide an metaphor. I teach a Martial Arts course @ OSU. I teach my students high kicks, sweeps, complex wrist techniques, etc. Some of it is pretty cool . However, I mostly teach them good footwork skills, and a sharp jab followed by a solid cross.
Does that mean that there are situations where a spinning wheel kick can't be the correct response, or that my students are incapable of them? Of course not: it simply means that they'll use the simplest technique available to them.
*Funny, story. One of my students entered a cage match a couple of years ago. Since we have no rank in our system, he just took his shirt off and entered the cage. His opponent was second degree bb in mo duck known: black belt, black uniform, very impressive looking. At the beginning of the match, the opponent let out a terrifying kia, ran across the cage, and leap into a flying side kick. It was very dramatic.
Tom looked @ me, shrugged, stepped out of the way, pushed the flyer out the air, and kicked him in the ribs while he was on the ground. End of fight. 7 seconds. And yes, kicking the other guy while he's down is perfectly legal in these things . Could Tom do a flying side kick? Yes, he does them beautifully. However, he does when justified, not just because he can.

If I were a developer I would try to get this skill, just in case. There certainly will be more opportunities in time

I encourage you to get these skills, and I'm happy to help that process in any way I can. Please don't misunderstand my suggestion. Understanding Unreferenced is a strick requirement for being a intermediate or advanced developer, IMO. I'm just saying that using it, in this particular assignment, is unnecessary. I have demonstrated as much, in that the WeakHashMap solution works as well for releasing locked records as the Unreferenced solutions.

and the assessors may change the way they mark this criteria.

But that's point, isn't it? That's not the way they currently mark this criteria. With this approach, you're coding to requirements that don't exist, for assessors who frown against this sort of thing. What the requirements might become, and what the assessors might choose to value in the future, won't help you with the current assignment.
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
ps - I promised you a threading issue. regardless of the synchronization and or locking algorithm you have in mind for Unreferenced, you explicitly have to code against deadlocks, because you have multiple objects being synchronized on in an unpredictable order, since the client can acquire a lock after Unreferenced is call on it.
Thus, you're opening the door to unthreadsafe code, for which you will and should fail if you don't get it exactly right: it's probably the most important part of your requirements. So far, no real solution has been offered outside of vague algorithms that come with disclaimers.
One such algorithm for resolving the deadlock pickle you're getting yourself into here is to use some sort of boolean, as Peter suggested, in your lock manager. However, that seems counter intuitive to me in an OO sense(why should the LockManager have to know about the problem that client has?). It's just clumsy.
However, the approach here is simply misguided: You don't need this problem. All of this is a deadlock resolution mechanism: what you really want here is a deadlock avoidance mechanism. AFIK, the best solution there is to a deadlock avoidance issue is not to lock on multiple objects. Especially if your specs don't require it: and I think we're agreed that the locking of multiple records by a given client isn't required(nor used). Thus, you don't need this headache, you're simply choosing to take it on.
I don't mean to be a harsh here, so my apologies if I seem overly critical of your design choices. but I am trying to defend what I consider to be a reasonable approch.
[ March 22, 2003: Message edited by: Max Habibi ]
[ March 22, 2003: Message edited by: Max Habibi ]

[Mark Spritzler]

What I think we have accomplished here, is a place for future SCJD goers to read about both sides and to make their own choice. There can't be a specific winner here, since they both have great merits and of course opinions.
Thank you everyone for participating and stating great arguments. We are all better for it.
Mark

[Max Habibi]

I've done my bit and went to the extent of using a mathematical argument.

Peter, I'm doing my bit by keeping the discussion focused. The first thing you need to prove is that we need to be able to map multiple records per client. then your thesis on why this or that implementation is better fit becomes relevant. As is, you've failed to establish the premise that invites the thesis, thus your argument is a non sequitur, regardless of if you support it by Set theory, Art history, or prayer. As a matter of fact, your argument is a non sequitur, regardless of it's state of correctness or incorrectness, because it offers a path trough woods that we haven't established needs to be crossed yet. The accuracy of the map is irrelevant at this point, because we don't know if we're need to go that way[/]. It simply shifts the discussion from decide [i]if we need to go to the accuracy of the map(no pun intended).

Now do your bit. Show me the gap. Show me where I miss the mark. Demonstrate. Don't just assert. Repeat it for my sake. Or link me the thread.

Once again, if I was unclear in the past, please accept my apologies. Take a step back and reexamine the discussion, because I know you're more interesting in being correct then being Right.
Because we have established the mapping multiple records to a given client is not a requirement, then any discourse on how a given algorithm supports it is a non sequitur. Similarly, because we have established that an audio interface to the application is not an requirement, any discourse of the best way to architect the application in audio feedback of such is a non-sequitor. Please let me know if I can make this more clear.

Of course it doesn't say that you need to make it generic, because it bloody well already is fully generic!

Is 'bloody' considered a curse in England? What does it mean anyway? I have the impression that it has some kind of religious significance? I think it's really cute

Are you trying to argue that fact is wholly irrelevant? A coincidence? A matter not to be considered at all when contemplating modifications to and extension of that class?

I'm pointed out that Sun expect you to modify and/or extend the Data class, and makes that clear. Thus, in the current version of the exam(though I can't speak to the earlier one that you took), either approach is justified. thus, modifying it is justified.

If so, you have a very strange approach to software development indeed.

Peter, I'm looking forward to a discussion soon that doesn't have you resorting to the above. I was hoping it could be this one: maybe next time? By all mean, poke holes in my ideas, disprove them, even educate me. But personal pot shots over the wire seems beneath you. I don't think you mean them as such(it would be funny if you did), but they aren't in line with high regard I have for your expertise.

quote:
--------------------------------------------------------------------------------
Not I, but you need to come up for a very compelling reason for ignoring the standard API. You want to ignore a standard object from the java.util package, in favor of a standard object from the java.rmi package.
--------------------------------------------------------------------------------
That's a bit too easy

There's a criticism of architecture I don't hear too often.
"Hey Al, using driving that rock is a 'bit too easy'. Let's tunnel through it.".
"Better yet, let's build an airlift."
"No, an Airlift is a 'bit too easy'. Let's go back home, build a teleportation device, and use that".
Peter, are you trying to put a smile on my face?

and rather meaningless. Your position, taken to its logical conclusion, means that all code one could possibly write satisfies Sun's requirement that "the design should use standard Java package facilities wherever possible" because all code ultimately uses java.lang.* and so forth.

Complete nonsense. My observation (it is not a position) is that you're advocating the usage of java.rmi.* package API instead of a java.util.* API. No reason to deny it, and there's no shame in it. It is, in fact, what you're doing. Defend it, not by denying that java.util.* APIs are non-standard java API 'in this case'. Make a case and prove your point. I'm looking forward to seeing it.

What it means is that, given a task, if there is a standard API to accomplish that task, you should use it. The standard API for doing something when all references to a Remote object get lost is Unreferenced. Fact.

Some things, not all things. There is context to consider. Since that 'something', in this case, can be handled by a more mainstream package( namely, java.util.*), it's my first choice. Fact.

You're ignoring this in favour of your own solution which involves garbage collector action on Remote objects. Fact.

This piece of rhetoric is not what I'd expect of you, Peter. By all means, discount aesthetics and elegance as purely subjective. That leaves the core of the argument, which was all about avoiding complexity in your algorithm. This is strictly measurable, and deliver real business benefits (or the lack thereof).

There is no gc involved in Unreferenced when a client crashes. Just the RMI DGC, and its action (in contrast to the JVM gc) is fully predictable here.

As a matter of fact, the gc is involved, because RMI needs to hold it off until the object has Unreferenced called on it, so the above is simply untrue. After a client crashes, the RMI DGC needs to get kicked of, which is does so, whimsically at the hands of the JVM. The DGC is fully analogous to the GC in this case, as shown here on the Sun site.

Distributed Garbage Collection: RMI uses its distributed garbage collection feature to collect remote server objects that are no longer referenced by any clients in the network. Analogous to garbage collection inside a Java Virtual Machine, distributed garbage collection lets you define server objects as needed, knowing that they will be removed when they no longer need to be accessible by clients.

At some point after that, after all references to the client have been released, the remote object has Unreferenced called on it, if the server runs for long enough. When this call occurs is whimsical in nature, and in the hands of the JVM. It also contains a great deal of complexity, and subtly, per the sun documentation.

"Many subtleties exist in the protocol; most of these are related to maintaining the ordering of referenced and Unreferenced messages in order to ensure that the object is not prematurely collected."

that you had better be prepared to answer for in your design doc, to explain that the object is not garbage collected while Unreferenced being called on it.
Thus, you have two levels of whimsy with Unreferenced: When the DMG is called to decrement the reference count, and when the server's JVM decides to call the Unreferenced method on the remoteObject.
The sun spec even specifically states that

remote references cannot guarantee referential integrity

deterministic behavior indeed.

After a client has been removed from the WeakHashMap, who is calling notifyAll() so that another client that may be waiting for the lock gets woken up? If my mental image of your code is correct, it doesn't happen. You have to wait an indefinite amount of time until a totally unrelated unlock event happens. If you happen to be working late and there's nobody else around, tough, you'll be around 'till the morning.

As you do with any sort of unpredictable process, including the calls to Unreferenced and the DMG. Surely you're not trying to imply that is a unique experience? The exact same issue pops up if a remote client crashes(or doesn't crash, but it's been so silent the server believes it crashed). You have to wait an indeterminate length of time before the DMG decides to collect that client's remote Object. Remember, the DGC is analogous to the gc in this context. But of course, you know this.

I wasn't referring to WeakHashMap performance, but to the performance penalty you pay for having the Map the wrong way around (lock() has O(N) performance rather than O(1)). No, performance is not a primary design goal, and not the most important part of the price to pay.

And I'm not going to correct you again, about the assumption that the map is the 'wrong way around' when it fits the requirements to a T, nor that you're avoiding unlock. Let's just agree the searching performance is a non-issue, and only bring it up again if we're tied, and need a tie breaker. Ok?

Another glib comeback.

Peter, have a sense of humor. And no, this wasn't particular glib. For glib, see above where I used your own reaction

Very good. WeakHashMap is not just another Map and you know it.

I do know it: and you better know that it too, if you want to be a developer and not a programmer(I don't mean you per se: I'm sure you're a fine developer). I don't think it's a particularly difficult concept. WeakHashMaps don't add to the reference count of the value. I don't find that particularly hard. As a matter of fact, I find it elegant.

If you have to understand how RMI works regardless, then you know how Unreferenced works, don't you?

Are you implying that understanding Unreferenced is a requirement to using general RMI services?

Because it's part and parcel of the RMI cleanup process that your WeakHashMap solution also relies upon, and (once you understand RMI DGC) a very straightforward part at that.

Are you saying that Unreferenced is part of the WeakHashMap solution? If so, I'm afraid I've failed to explain it to you properly. My apologies.

Sequitur.

Not at all. If you suggesting that the WeakHashMap needs the Unreferenced interface, then you are simply misinformed. If you are not saying that WeakHashMap requires Unreferenced, then it's a non sequitur.

No, I don't know this. The RMI DGC does not operate like the JVM garbage collector at all,

Demonstrably false.
From the sun spec:

Analogous to garbage collection inside a Java Virtual Machine, distributed garbage collection lets you define server objects as needed, knowing that they will be removed when they no longer need to be accessible by clients.

It does not operate like the JVM garbage collector at all? Please.

Specifically, when a client crashes you are guaranteed to be notified when the DGC lease expires (assuming no other references remain). A WeakHashMap-based solution piles the server-side gc on top of the DGC action, and adds its unpredictability to it.

Again, a fuss is being made over a non issue. It's either the GC on top of the DMG, or Unreferenced on top of the DMG, then followed by GC. The WeakHashMap simply cuts out the middle man, and avoid one last call to the RemoteObject.
HTH,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ March 22, 2003: Message edited by: Max Habibi ]

[Max Habibi]

Originally posted by Mark Spritzler:
What I think we have accomplished here, is a place for future SCJD goers to read about both sides and to make their own choice. There can't be a specific winner here, since they both have great merits and of course opinions.
Thank you everyone for participating and stating great arguments. We are all better for it.
Mark

Mark is right. Peter, you may have the last word. After that, I'm closing this thread .
M

[HS Thomas]

There are still relevant issues to be discussed, I think. Don't tell we we're boring you .

Not at all .Didn't realise there's lot's more.
Perhaps it's all a question of drawing boundaries of the system.
WeakHashMap has a smaller boundary than Unreferenced. There are obvious benefits in starting off small. Peter's concern seems to be that when the boundary get's stretched, what guarantees do you have that WeakHashMaps short-comings i.e. non-ability to lock multiple records for a client, no guarantees for releasing of locks, will be addressed and not left as it is to compromise the whole design eventually.
Note: I said WHEN you stretch the boundaries as all systems must do at some time.
So what do you put within your boundary to make sure the design isn't compromised and what can you safely leave out?
In the context of the assignment , this may not be an issue.
I think the chart has been taken as far as it can go. We have covered the core technical issues and put weightings on it but are now encroaching on softer issues of software development. This is even harder to apply weightings to.
Note , that the weightings are my own, and others may/may not agree with them.
I'll read through the material you have provided and wait for any response , to see how the weightings as I have put down get affected.
Sticking to the core issues we have covered.
I don't expect the chart to grow any further. I think that will defeat it's purpose.
The softer issues are well-worth debating on another thread. Perhaps another forum ?
regards
( See, I have drawn another boundary, here )
[ March 23, 2003: Message edited by: HS Thomas ]