lock question (regarding client ID

[Boris Milojkovic]

Hi all, (my first post)
Eny client has its own thread of exec. When rmi call happens, that thread is
mapped to rmi thread (on "server side"). If that thread is blocked, it can not
be reused (by rmi rt)??? If this is true, what prevent us from using threadID as clentID?

[Peter den Haan]

Originally posted by Boris Milojkovic:
[...] If this is true, what prevent us from using threadID as clentID?

This section from the RMI spec: 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. [...] Although not everyone seems to agree on the interpretation of these two sentences, for me the core consists of the words "no guarantees". Make no assumptions whatsoever about which thread executes what when.
Yes, you can use the thread ID and make stuff work with the current RMI implementation. It's a bad idea for the same reason that using com.sun.* classes is a bad idea. It may not work on someone else's JRE. It may well stop working in Sun's next version of Java. And programming to non-public API (or behaviour) is bad practice in general.
- Peter
[ February 17, 2003: Message edited by: Peter den Haan ]

[Mark Spritzler]

Simply because there is no guarantee that that thread ID will always be used by that client. It is in the RMI specs.
However, some others have tested this and have found the same thread ID, but you are taking a risk.
Why not do a search for our lovely "Connection object". You will find many food for thought on client IDs.
But the Peter can sneak in and post before you get to because you are in a phone meeting, and can't hit submit post.
Mark
[ February 17, 2003: Message edited by: Mark Spritzler ]

[Max Habibi]

Originally posted by Boris Milojkovic:
Hi all, (my first post)
Eny client has its own thread of exec. When rmi call happens, that thread is
mapped to rmi thread (on "server side"). If that thread is blocked, it can not
be reused (by rmi rt)??? If this is true, what prevent us from using threadID as clentID?

Hi Boris,
You are correct: there are no known implementations on RMI, on any platform, that do use a separate thread for successive calls to the same object, for a given client.
This is the other interpretation of the spec that Peter is referring to. That is, if client Peter holds a reference to Remote Object Juliet, and client Mark also holds a reference to Remote Object Juliet, then, IMO, the spec is saying:

There is no guarantee that, even as Peter is speaking to Juliet, that Mark will not call her and ask her to do something that would upset Peter. If Peter and Mark want to ask Juliet to not accept calls from a second person when she's already talking to someone, then they need to make those arrangements beforehand.

The other possibility that Juliet only has a single phone line, in which case she will only accept a single caller at a time. This is the case where she uses a single thread for all calls, in which case you, Mark, and Peter will also be safe.
So the bottom line is, you could implement your server in the way you're describing, and still be 100% compliant with the requirement that your code be portable(unless some operating system, somewhere, decides to change their implementation of RMI between now and the time you submit your assignment), for a given JRE. In other words, Juliet can assume that, since Peter called her on line 1, when she picks up line 1, Peter will be at the other end.
What she can't assume, and what Mark can't assume, is that Peter won't ask her to do something naughty. As a matter of fact, he probably will .
It could be argued that it's bad practice to design for non existent requirements, if they increase the complexity of your code. However, that being said, there are many people who have implemented their code by using explicit client IDs, and they have earned reasonable scores.
One last bit of advice: Either way, consider using a WeakTreeMap to hold clientIDs-locks, and make sure that the only reference to that client ID is held by the client. That way, if the client dies, the reference to the clientID will die, and the lock will automatically be released.
Good luck,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ February 17, 2003: Message edited by: Max Habibi ]

[Peter den Haan]

Originally posted by Max Habibi:
Peter, I think there's a little confusion about the way the distributed garbage collector works: Internally, it relies on the local garbage collector.

I'm probably a bit thick, Max, but can you point out explicitly where the material you linked to supports this
statement?
While we agree there's a little confusion about the way the distributed garbage collector works, we disagree on who is confused. There is no reliance whatsoever on the server-side garbage collector.
Section 3.3 of the RMI specification explicitly describes the mechanics behind the operation of the DGC. If you read it carefully, you will see that it relies on the client-side garbage collector or,
if client or network crashes, on the expiration of the client's lease.
It is of course impossible for an excerpt to show that something is not being said in an entire spec, but for those who don't want to read the the RMI spec the core sentence is perhaps As live references are found to be unreferenced in the local virtual
machine, the count is decremented. When the last reference has been discarded, an unreferenced message is sent to the server. My emphasis. The server DGC does simple bookkeeping; the server-side garbage collector never even enters the picture.

The 'simplicity' that you're talking about is illusionary: You're simply going the long way around the block, for the sake of going the long way around the block.

It should be clear from the above that this is just plain wrong. Unreferenced does not involve the server-side garbage collector at all. Using a WeakHashMap rather than the Unreferenced callback completely unnecessarily adds the server-side garbage collector into the mix.
I would like to point out that the same section 3.3 I quoted above states that a remote object needing unreferenced notification must implement the java.rmi.server.Unreferenced interface. I would also like to point out that one of the marking criteria, as stated in
the instructions, is use of java core packages rather than re-invention. Really, I don't think that anything more can be said.

This is an interesting contention, and I would like to see supported, which it is not below. Again, I think there is some confusion in the premise, and the content on your argument.

Now that I would like to see supported. While not rigorous in the scientific sense, I skipped few steps. Let's see.

1. To be brief, your first contention is that a mapping of locks to clients should be modeled as a map: While this is true, it is a non-sequalar, since you have not (yet) established that this is the appropriate path to take.

It is not a non-sequitur,
as I did not set out to prove that a Map is the best implementation. No such proof exists for any nontrivial programming problem, as you well know. I set out to prove that a Map from records to clients is superior than a Map the other way around, and this is exactly what my conclusion states. This does follow from the argument. If you think it doesn't, show why. Don't just assert.

2. Your second argument, that locking based on record id produces faster searches, is also flawed. First, you're assuming that the unlock mechanism would first check the locked status of the record, when in reality it would actually check the locked status of the
client.

Have you read the argument you're trying to refute? No such assumption was made. In fact it stated in as many words that "Removing a lock can be done by client and is O(1)." It's the locking that kills you. Significantly, you don't say a word about that.

Second, you're forgetting that structure would be searched not by record index, but by the Integer that represents that record. And searching for an Object that happens to be an Integer is no faster then searching for an Object that happens to be String.

An obvious fact. Its relevance escapes me for the moment, unfortunately. I don't care in the least what exactly you're searching for; searching the value collection of a Map is an O(n) operation.

However, even if you were correct, this is also a non starter, since performance is not a motivation for the design of this project. [...]

And as much is stated at the end of my reply. Nice thing is, inverting the map doesn't actually make the code any
more complex. That makes the issue really simple, doesn't it?
One difference between the two approaches is whether you can use WeakHashMap to do cleanup, which we both agree is not required. Whether a WeakHashMap is less complex than a three-line Unreferenced implementation is at the very least debatable -- surely you can grant as much. In any case, I wasn't really addressing the cleanup debate in my four perspectives, just the question how the lock map (if any) should work.

3. Your third perspective [is] not a part of the requirements, nor is it implied by information supplied by their usage [...] this is also a non starter.

No, this is not strictly required, as stated with as many words at the end of my argument. That doesn't render it insignificant.
Take another look at the Data class. It is not a flights database. It is a generic database class. It may have been written for the Fly By Night project, but it was without a shadow of a doubt written with reuse in mind. This is the class you are being asked to modify. This is the class you are being asked to extend to a networked version. That should tell you something. That, too, is part of your instructions, even if it isn't in the "instructions.html" file. I don't know what kind of environment you are working in, but in my place, one is encouraged to write reusable code especially where this can be done without increasing the complexity. Conversely, we strongly discourage developers from building in arbitrary limitations without a good reason. Simplicity can be a good reason. It isn't here, because there is no gain in simplicity. Inverting the lock map doesn't reduce your lines of code, and it doesn't make the code easier to understand (to the contrary, because the data structure becomes significantly less expressive of the problem; see the fourth perspective).

4. Your final perspective is that you like your own design better. [...]

This piece of rhetoric is not what I'd expect of you, Max. By all means, discount aesthetics and elegance as purely subjective. That leaves the core of the argument in my fourth perspective, which was all about clarity, robustness and expressiveness. All of these are objective and measurable (even if measuring them isn't necessarily easy), and deliver real business benefits (or the lack thereof).

However, let's consider the balance of the objective evidence.
A. Using the Distributed garbage collector is not more 'simple', or 'elegant' then simply using the garbage collector.

Where to start?

This is an irrelevant comparison between apples and pears. You are using the DGC whatever you do. The only difference is that a WeakHashMap relies on ordinary server-side garbage collection in addition to the DGC mechanism.

It is "more 'simple', or 'elegant'" in the sense that using published and documented Java API is "more 'simple', or 'elegant'" than using undocumented and non-deterministic behaviour. Undocumented, unless you can show that the spec guarantees that RMI's internal local references to Remote objects are released immediately. Non-deterministic because the garbage collector is non-deterministic.

Your honour, these are just the two most important reasons why exhibit A should be thrown out of this court as impermissible and irrelevant

B. There is no requirement that clients be allowed to lock a more then a single record at a time.

This is true, and at no point did I dispute this. That does not make such a restriction desirable. Please see the last bit of my previous response. It also fails to address the other three perspectives on the lock map issue.

It seems to me that your design has a lot of everything (call backs, unnecessary requirement implementation, DGC, etc.,), that can be removed.

Beside the point and not true.

This is quite orthogonal to the lock map issue. I had hoped to avoid re-opening the Unreferenced discussion by merely mentioning it as an alternative and pointing out that opinions differ with a link to our earlier thread.

We both agree, have always agreed, and will always agree that this cleanup is not a requirement and can be removed. That applies both to using WeakHashMap and to implementing Unreferenced. We were discussing which, if you would implement this
non-required functionality, would be preferable. "Unnecessary requirement implementation" could've been cheap point-scoring if that were your style.

Callbacks; yes, there's a callback. IMHO, it's absolutely simpler than WeakHashMap (and that is in addition to being published and deterministic API). Complexity is in more than just LOC. And remember that we're talking about three lines of code in total: one method containing one simple statement. Some callback.

DGC: you use DGC whichever way you go. Unless you don't implement cleanup in the first place.

etc: hand-waving.

As always, thanks for the discussion, Max. We really disagree here, and unfortunately it seems you didn't address any of the points I raised. Maybe I didn't express myself quite clearly enough, in which case, accept my apologies and I hope the above will act as a clarification. I am looking forward to seeing a solid, rational argument establishing why I'm wrong.
- Peter
[ February 24, 2003: Message edited by: Peter den Haan ]

[Max Habibi]

Originally posted by Peter den Haan:
I'd like to add to this that you may choose to implement the java.rmi.server.Unreferenced interface as an alternative way to achieve the same thing, with the added advantage that you wouldn't have to wait for the server-side garbage collector to kick in. Opinions differ on which way is simpler.

Peter, I think there's a little confusion about the way the distributed garbage collector works: Internally, it
relies on the local garbage collector. The 'simplicity' that you're talking about is illusionary: You're simply going the long way around the block, for the sake of going the long way around the block.

The main reason I followed up on this is that the suggested Map would be the wrong way around.

This is an interesting contention, and I would like to see supported, which it is not below. Again, I think there is some confusion in the premise, and the content on your argument.
1. To be brief, your first contention is that a mapping of locks to clients should be modeled as a map: While this is true, it is a non-sequalar, since you have not (yet) established that this is the appropriate path to take. You might as well offer a perspective that painting is best accomplished by using a paintbrush: while this is an interesting observation, it is not a argument.
2. Your second argument, that locking based on record id produces faster searches, is also flawed. First, you're assuming that the unlock mechanism would first check the locked status of the record, when in reality it would actually check the locked status of the client. Second, you're forgetting that structure would be searched not by record index, but by the Integer that represents that record. And searching for an Object that happens to be an Integer is no faster then searching for an Object that happens to be String.
However, even if you were correct, this is also a non starter, since performance is not a motivation for the design of this project. Especially since a architecture that offers more complexity, at the price of a small performance enhancement, is not justified.
3. Your third perspective, basically, is that user might be better served if they lock more then a single record at a time. Since this not a part of the requirements, nor is it implied by information supplied by their usage, nor is it a feature the client asked for(maybe the client doesn�t want reservation locked if they are not being booked?) nor, as I understand it, are you suggesting that the UI allow the users to actually lock more then a single record at a time, this is also a non starter.
4. Your final perspective is that you like your own design better. Well, that can hardly be argued with.
However, let's consider the balance of the objective evidence.
A. Using the Distributed garbage collector is not more 'simple', or 'elegant' then simply using the garbage collector.
B. There is no requirement that clients be allowed to lock a more then a single record at a time.
Accord to Don Lancaster, in the
link you so thoughtfully provided

elegant simplicity comes when you have removed everything that you can.

It seems to me that your design has a lot of everything (call backs, unnecessary requirement implementation, DGC, etc.,), that can be removed.

All best,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ February 22, 2003: Message edited by: Max Habibi ]

[Peter den Haan]

Before I start, it is worth stating explicitly that I think there are two discussions: (1) if you keep track of your locks in a Map, should you map client IDs to records or vice versa, and (2) should you want to implement some kind of cleanup mechanism, is using a WeakHashMap the best way, or is implementing Unreferenced the best way. Although the outcome of (1) has some bearing on (2), I'd like to view them as separate discussions; in my response above, I actually wanted to engage in discussion (1) while avoiding discussion (2). It seems that the genie has once more been allowed out of the bottle, though

Originally posted by Max Habibi:
Peter, I think there's a little confusion about the way the distributed garbage collector works: Internally, it relies on the local garbage collector.

I'm probably a bit thick, Max, but can you point out explicitly where the material you linked to supports this statement? With "local garbage collector", I'll assume you mean the server-side one, as that's what I was explicitly referring to above.
While we agree there's a little confusion about the way the distributed garbage collector works, we disagree on who is confused. There is no reliance whatsoever on the server-side garbage collector. Section 3.3 of the RMI specification explicitly describes the mechanics behind the operation of the DGC. If you read it carefully, you will see that it relies on the client-side garbage collector or, if client or network crashes, on the expiration of the client's lease.
It is of course impossible for an excerpt to show that something is not being said in an entire spec, but for those who don't want to read the the RMI spec the core sentence is perhaps As live references are found to be unreferenced in the local virtual machine, the count is decremented. When the last reference has been discarded, an unreferenced message is sent to the server. My emphasis. The server DGC does simple bookkeeping; the server-side garbage collector never even enters the picture.

The 'simplicity' that you're talking about is illusionary: You're simply going the long way around the block, for the sake of going the long way around the block.

It should be clear from the above that this is just plain wrong. Unreferenced does not involve the server-side garbage collector at all. Using a WeakHashMap rather than the Unreferenced callback completely unnecessarily adds the server-side garbage collector into the mix.
I would like to point out that the same section 3.3 I quoted above states that a remote object needing unreferenced notification must implement the java.rmi.server.Unreferenced interface. I would also like to point out that one of the marking criteria, as stated in the instructions, is use of java core packages rather than re-invention. Really, I don't think that anything more can be said.

This is an interesting contention, and I would like to see supported, which it is not below. Again, I think there is some confusion in the premise, and the content on your argument.

Now that I would like to see supported. While not rigorous in the scientific sense, I skipped few steps. Let's see.

1. To be brief, your first contention is that a mapping of locks to clients should be modeled as a map: While this is true, it is a non-sequalar, since you have not (yet) established that this is the appropriate path to take.

It is not a non-sequitur, as I did not set out to prove that a Map is the best implementation. No such proof exists for any nontrivial programming problem, as you well know. I set out to prove that a Map from records to clients is superior than a Map the other way around, and this is exactly what my conclusion states. This does follow from the argument. If you think it doesn't, show why. Don't just assert.

2. Your second argument, that locking based on record id produces faster searches, is also flawed. First, you're assuming that the unlock mechanism would first check the locked status of the record, when in reality it would actually check the locked status of the client.

Have you read the argument you're trying to refute? No such assumption was made. In fact it stated in as many words that "Removing a lock can be done by client and is O(1)." It's the locking that kills you. Significantly, you don't say a word about that.

Second, you're forgetting that structure would be searched not by record index, but by the Integer that represents that record. And searching for an Object that happens to be an Integer is no faster then searching for an Object that happens to be String.

An obvious fact. Its relevance escapes me for the moment, unfortunately. I don't care in the least what exactly you're searching for; searching the value collection of a Map is an O(n) operation.

However, even if you were correct, this is also a non starter, since performance is not a motivation for the design of this project. [...]

And as much is stated at the end of my reply. Nice thing is, inverting the map doesn't actually make the code any more complex. That makes the issue really simple, doesn't it?
One difference between the two approaches is whether you can use WeakHashMap to do cleanup, which we both agree is not required. Whether a WeakHashMap is less complex than a three-line Unreferenced implementation is at the very least debatable -- surely you can grant as much.
In any case, I wasn't really addressing the cleanup debate in my four perspectives, just the question how the lock map (if any) should work.

3. Your third perspective [is] not a part of the requirements, nor is it implied by information supplied by their usage [...] this is also a non starter.

No, this is not strictly required, as stated with as many words at the end of my argument. That doesn't render it insignificant.
Take another look at the Data class. It is not a flights database. It is a generic database class. It may have been written for the Fly By Night project, but it was without a shadow of a doubt written with reuse in mind. This is the class you are being asked to modify. This is the class you are being asked to extend to a networked version. That should tell you something. That, too, is part of your instructions, even if it isn't in the "instructions.html" file. Where I work, one is encouraged to write reusable code especially where this can be done without increasing the complexity. Conversely, we strongly discourage developers from building in arbitrary limitations without a good reason. Simplicity can be a good reason. It isn't here, because there is no gain in simplicity. Inverting the lock map doesn't reduce your lines of code, and it doesn't make the code easier to understand (to the contrary, because the data structure becomes significantly less expressive of the problem; see the fourth perspective).

4. Your final perspective is that you like your own design better. [...]

This piece of rhetoric is not what I'd expect of you, Max. By all means, discount aesthetics and elegance as purely subjective. That leaves the core of the argument in my fourth perspective, which was all about clarity, robustness and expressiveness. All of these are objective and measurable (even if measuring them isn't necessarily easy), and deliver real business benefits (or the lack thereof).

However, let's consider the balance of the objective evidence.
A. Using the Distributed garbage collector is not more 'simple', or 'elegant' then simply using the garbage collector.

Where to start?

This is an irrelevant comparison between apples and pears. You are using the DGC whatever you do. The only difference is that a WeakHashMap relies on ordinary server-side garbage collection in addition to the DGC mechanism.

It is "more 'simple', or 'elegant'" in the sense that using published and documented Java API is "more 'simple', or 'elegant'" than using undocumented and non-deterministic behaviour. Undocumented, unless you can show that the spec guarantees that RMI's internal local references to Remote objects are released immediately. Non-deterministic because the garbage collector is non-deterministic.

Your honour, these are just the two most important reasons why exhibit A should be thrown out of this court as impermissible and irrelevant

B. There is no requirement that clients be allowed to lock a more then a single record at a time.

This is true, and at no point did I dispute this. That does not make such a restriction desirable. Please see the last bit of my previous response. It also fails to address the other three perspectives on the lock map issue.

It seems to me that your design has a lot of everything (call backs, unnecessary requirement implementation, DGC, etc.,), that can be removed.

Beside the point and not true.

This is quite orthogonal to the lock map issue. I had hoped to avoid re-opening the Unreferenced discussion by merely mentioning it as an alternative and pointing out that opinions differ with a link to our earlier thread.

We both agree, have always agreed, and will always agree that this cleanup is not a requirement and can be removed. That applies both to using WeakHashMap and to implementing Unreferenced. We were discussing which, if you would implement this non-required functionality, would be preferable. "Unnecessary requirement implementation" could've been cheap point-scoring if that were your style.

Callbacks; yes, there's a callback. IMHO, it's absolutely simpler than WeakHashMap (and that is in addition to being published and deterministic API). Complexity is in more than just LOC. And remember that we're talking about three lines of code in total: one method containing one simple statement. Some callback.

DGC: you use DGC whichever way you go. Unless you don't implement cleanup in the first place.

etc: hand-waving.

As always, thanks for the discussion, Max. We really disagree here, and unfortunately it seems you didn't address any of the points I raised. Maybe I didn't express myself quite clearly enough, in which case, accept my apologies and I hope the above will act as a clarification. I am looking forward to seeing a solid, rational argument establishing why I'm wrong.
- Peter
[ February 24, 2003: Message edited by: Peter den Haan ]

[Max Habibi]

As always, thanks for the discussion, Max. We really disagree here, and unfortunately it seems you didn't address any of the points I raised. Maybe I didn't express myself quite clearly enough, in which case, accept my apologies and I hope the above will act as a clarification. I am looking forward to seeing a solid, rational argument establishing why I'm wrong.

Peter,
In the interest of the civil and rational debates we've had in the past, and future one I look forward to, I'm going to start this discussion from a clear slate.
I can see the current discussion degenerating quickly, and I'd like to avoid that.
I think you have a valuable insight to provide to this discussion, and I'd like to encourage you to make that contribution.
I'd also like for both of us to make an effort to be logical, as opposed to rhetorical and/or satirical. I think that, together, we can illuminate some of the pro and cons of various approaches.
Let's start with our goals and assumptions. Please feel free to correct any of these assumptions, and propose new ones. I'm currently under the impression that we both agree on all of the following points.
Goal: the comparison a distributed lock release algorithm for the SCJD assignment. The two algorithms, broadly speaking, are the use of the Unreferenced interface, versus the use of a WeakHashMap on the server.
Assumption 1: releasing locked clients records is not a requirement of the SCJD assignment.
Assumption 2: releasing locked clients records is desirable, if it can be achieved with a minimal complexity.
Assumption 3: Clients are not required to be able to lock more then a single record at a time.
Assumption 4: Both the WeakHashMap approach, and the Unreferenced approach, will work, as far as the goal of cleaning up 'lost' locks is concerned.
Ground rules: all statements that both you and I agree to are to be considered assumptions, thus requiring no further proof.
Up for it? If so, please make start by making your case. Or it you prefer, I can start.
All best,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ March 08, 2003: Message edited by: Max Habibi ]

[Peter den Haan]

Hi Max,
Unfortunately I missed your last f'up on this. The idea looks great. Ack on all assumptions, with the following notes.

Originally posted by Max Habibi:
Assumption 3: Clients are not required to be able to lock more then a single record at a time.

True; however, as the ability to acquire multiple locks would improve reusability of your server classes I would at least classify this ability as a "nice-to-have".

Assumption 4: Both the WeakHashMap approach, and the Unreferenced approach, will work, as far as the goal of cleaning up 'lost' locks is concerned.

Agreed, provided that the keys in the WeakHashMap are the Connection objects. We still have this other unresolved question whether using the Thread to give the client identity is a good idea or not. It is probably best to keep the discussion clean and ignore this issue.
- Peter

[John Smith]

Peter wrote:

We still have this other unresolved question whether using the Thread to give the client identity is a good idea or not.

Actually, that has been settled. As Max reported here, "It is, in fact, possible for a single client, bound to a single remote instance, to have it's methods called by various threads."
Eugene.

[Peter den Haan]

Ah. Excellent. I'd missed that thread, thanks.
- Peter

[Max Habibi]

True; however, as the ability to acquire multiple locks would improve reusability of your server classes I would at least classify this ability as a "nice-to-have".

I don't agree that it's a "nice to have", because we don't really know enough about the business: Maybe it hurts business to have agents lock more then a single client at a time: we, as developers, just don't know. At this point, we're reduced to guessing and assuming: and again, that's the point where I feel it's generally best to do no harm first and foremost. Let's leave the contention that this is a "nice to have" as unproven. There are, I think, reasonable arguments of both sides, but neither side overwhelmingly convincing. Do you agree?
M, author
The Sun Certified Java Developer Exam with J2SE 1.4

[Max Habibi]

Agreed, provided that the keys in the WeakHashMap are the Connection objects. We still have this other unresolved question whether using the Thread to give the client identity is a good idea or not. It is probably best to keep the discussion clean and ignore this issue.

This was actually an interesting test. It seems that RMI does spawn a thread per each unique object(up to a point, I'm sure: but I wasn't able to hit that point with 100 seperate clients): however, once that object is released, the RMI thread that was tending to it's needs will hang around, and try to accomadate the needs of other remote objects.
M

[Peter den Haan]

Originally posted by Max Habibi:
I don't agree that [multiple locks are] "nice to have", because we don't really know enough about the business: Maybe it hurts business to have agents lock more then a single client at a time: we, as developers, just don't know. [...] There are, I think, reasonable arguments of both sides, but neither side overwhelmingly convincing. Do you agree?

Well, to be honest, no. Data is a completely generic, perfectly business-agnostic class. The requirements strongly steer us in the direction of building an equally business-agnostic generic database server. Business-driven restrictions on the number of locks, in contrast, are purely application-specific and should therefore be no consideration in our server design (complexity might be though).
Then there's the reusability angle; surely reusability is a "nice-to-have" in any environment! By restricting clients to one lock only we certainly are restricting applications and thereby the reusability of the class. Enabling multiple locks per client does not restricting application-level functionality in any way; any constraint can be enforced by the application where it belongs.
There's also the fact that the supplied javadoc, which is the most precise specification for this feature that we have, does not even hint at any restrictions in the number of locks held.
I find it very hard to see how one could argue with the "nice-to-have-ness" of this feature.
Even so, I would be happy to let the matter rest if it weren't for the fact that it is a symptom of the underlying, much more serious problem that the inversion of the Map turns an excellent and faithful representation of the problem domain into a very poor one. That is the underlying cause which gives rise to this restriction; you're trying to shoehorn a square problem into a round data structure, and reap the results in the form of harder to read code, arbitrary restrictions, and poor big-O performance/scalability.
- Peter
[ March 20, 2003: Message edited by: Peter den Haan ]

[Max Habibi]

Originally posted by Peter den Haan:
Well, to be honest, no. Data is a completely generic, perfectly business-agnostic class.

Yes it is. However, we are not in an agnostic business here: we're in the Fly By Night business. Thus, while data is 'perfectly' business agnostic, Fly by Night isn't.
While it is reasonable to keep data generalized, it's also reasonable specialize it. That's why the requirements state that, should you decide to extend the class or modify it, you need to state your reasons. Obviously, the people who designed the test felt that modifying the class was a reasonable choice.

The requirements strongly steer us in the direction of building an equally business-agnostic generic database server.

I'm surprised that you would think that: maybe you had a different version of the test then the most recent version. There is nothing in the requirements that steers us this way. As a matter of fact, the requirement explicitly steer us towards less complexity, which generally means more specific solutions. Generally speaking, more specific implies less less complexity: this is one of the reasons that developers prefer set requirements when starting a project: because it allows us to narrow scope. However, I'm sure you know this.

Business-driven restrictions on the number of locks of the kind that you are discussing here, on the other hand, are purely application-specific.

Yes, and so is the Fly By Night Application which you are writing. Remember, you've been hired by Fly By Night here. You're not a consultant who's creating a shrink wrapped product that you can then turn around and sell to another client.

By restricting clients to one lock only we certainly are restricting applications and thereby the reusability of the class.

There are no 'applications': only a single application. Writing code for non existing applications increases complexity, which is the exact opposite of the directive the students are given here.

Enabling multiple locks per client does not restricting application-level functionality in any way;

Nor does enforcing single lock per client.

any constraints can be enforced by the application where it belongs. I find it very hard to see how one could argue with the "nice-to-have-ness" of this feature.

I'm surprised to hear you say that. If it serves no business function for our client, and no application function for our code, then it's just fat. This has always been the way of good software.

Quite apart from the fact that the supplied javadoc, which is the most precise specification for this feature that we have, does not even hint at any restrictions in the number of locks held.

Quite apart indeed. The javadoc does not even hint at pink elephants dancing around the border, or an interface for the deaf. However, a good developer will choose to exclude those also, because they do not serve a business function, per the specifications

Even so, I would be happy to let the matter rest if it weren't for the fact that it is a symptom of the underlying, much more serious problem that the inversion of the Map makes turns an excellent and faithful representation of the problem domain into a very poor one.

Saying that the inverted map is an 'excellent' and 'faithful' representation of the problem does not make it so, as I'm sure that someone with your skill in discussion is aware. You have presented arguments about why you feel that it is an excellent reason: they have been answered. Your premise is that this keeps the solution more generic. However, this generic nature is 1) unspecified in the requirements, and 2) requires more work, and 3) complicates locking(which assertion I have not proven yet). thus, there is no complelling case for excellence or faithfullness: they are simply the words you have chosen. Do you see where it is reasonable to hold an opinion on this topic that is different then your own, if I reject the premise that the only reasonable implemation of the Data class is a generic one?

That is the underlying cause which gives rise to this restriction; you're trying to shoehorn a square problem

Peter, I expect better from you. I specfically restarted this thread, because I wanted us to focus on the merits of the arguments, and not on the suspected motivations of the fellow we're discussing this topic with. As the moderator of this forum, I'm making this a ground rule. Thus, no more 'you are trying to', etc. Demonstrate, and argue on the merits. If you can prove that locking multiple locks per clients is the only reasonable choice, then please do so. If you cannot, then please admit that locking multiple records per c;ient is not the only reasonable choice. And if it is not the only reasonanble choice, then you can see where there is room for dispute that this one reasonable choice is but one of at least two.
Let me put it this way: do you feel you are able to argue your case without the requirement that a locks/client map is a desirable? If so, in the interest of further discussion, I am willing to grant it, assumming that we can agree that it should drop by the wayside in the face of providing a less complex solution that is more easily understood by a junior programmer.
Either way, let me know.
All best,
M

[Peter den Haan]

Originally posted by Max Habibi:
I'm surprised that you would think that [the requirements strongly steer us in the direction of building an equally business-agnostic generic database server]: maybe you had a different version of the test then the most recent version.

I did, and it had a much stronger emphasis on re-use than the current one (to the point of explicitly stating that the database stuff was going to be re-used in the future), which might colour my thinking. But regardless of that: (1) Data is fully generic. (2) The Data API is the API of a fully generic database. (3) You are strongly steered towards exposing your database server using the Data API.
Now if the stuff you're writing is just for the FBN client, the design you're being forced into makes no good sense whatsoever. That, together with the evident genericity and reusability of the Data class itself, seems highly significant.

There are no 'applications': only a single application. Writing code for non existing applications increases complexity, which is the exact opposite of the directive the students are given here. [...] You're not a consultant who's creating a shrink wrapped product that you can then turn around and sell to another client.

This is rather a distortion of the point I'm trying to make.
I'm still totally stumped how you can possibly argue that better reusability is not a nice-to-have. It is always a nice to have; even when you decide that the extra effort isn't worth it, that it's not quite nice enough to justify the price, that doesn't make it any less of a nice-to-have.
Specifically, if introducing an (in this context) unimportant restriction greatly simplifies matters, go for it -- you can do the extra work when you indeed come around to reusing the class. We do not disagree on this, and please don't make it look as if we are. Reducing reuse like that needs some form of justification such as lower complexity, better performance, whatever. In this case, it has none of these. To the contrary.

The javadoc does not even hint at pink elephants dancing around the border, or an interface for the deaf. However, a good developer will choose to exclude those also, because they do not serve a business function, per the specifications

Very funny, or silly, depending on how you look at it. To my memory, the assignment supplies no javadoc for either pink elephants or interfaces for the deaf. There is, however, a javadoc specification for the lock() and unlock() functions, and it provides essential instructions for the assignment (e.g. the whole client ID issue). If you do not think that this same javadoc should clearly document restrictions on the number of locks that can be held, I will never want to use or maintain your software!
If, on the other hand, you think that modifying the supplied contract in the interest of simplicity is OK, then why not simply remove from unlock() the awkward requirement that unlocking a record you don't own should have no effect? After all, you're coding just for the FBN application which you know would never do such a thing. So you can scrap all of that, no?
Your position is just not consistent, Max, and in the light of that, turning what I'm saying into idiocy with elephants isn't the most convincing of responses. Please give a clear answer: is it OK to modify the supplied contract (as described by the javadoc) if the modifications work for FBN and it makes things lots simpler, or isn't it? If it is, then why not remove the whole client-ID business? If it isn't, then what's this number-of-locks-restriction business about?

Saying that the inverted map is an 'excellent' and 'faithful' representation of the problem does not make it so, as I'm sure that someone with your skill in discussion is aware. You have presented arguments about why you feel that it is an excellent reason: they have been answered.

They have never been answered; you have followed up on them, which is something entirely different. Core problem domain constraints like "you can give a record lock only to one client at a time", "the locked records form a Set", "there is no a priori reason why a client cannot hold more than one lock" are fully expressed with the map in one direction and not at all with the map in the other direction. Fact. This mismatch between problem and solution expresses itself in a number of ways, ranging from restrictions via code readability to performance. See earlier threads for all the gory details.

[...] this generic nature is 1) unspecified in the requirements, and 2) requires more work, and 3) complicates locking (which assertion I have not proven yet)

You haven't proven item 2) either -- and won't ever be able to, since it doesn't require more work. It's a pity that we aren't able to post code here because it would help make things pretty obvious. Regarding 1), well, no good developer needs encouragement when it becomes clear that an implementation can be made more generic with no extra effort. Often, the more generic version turns out to be simpler to understand and maintain as well, simply because the code is a better fit for the problem.

"That is the underlying cause which gives rise to this restriction; you're trying to shoehorn a square problem"
Peter, I expect better from you. I specfically restarted this thread, because I wanted us to focus on the merits of the arguments, and not on the suspected motivations of the fellow we're discussing this topic with. As the moderator of this forum, I'm making this a ground rule. Thus, no more 'you are trying to', etc.

I was looking for an analogy to describe the mismatch between problem and solution if you do the map the wrong way around; I'm not conscious of ascribing specific motivations to you. However, if this offended, then please accept my apologies.

Demonstrate, and argue on the merits. If you can prove that locking multiple locks per clients is the only reasonable choice, then please do so.

I'm not trying to argue that "locking multiple locks per clients is the only reasonable choice" in isolation. As I said, it is merely one symptom of a deeper issue: how do I model my problem using a Map? I have demonstrated why, quite extensively, as I remember. For example, I even dragged set theory into it to show that the problem fits the map in one way only. There has been nothing to refute it.
- Peter
[ March 20, 2003: Message edited by: Peter den Haan ]

[Max Habibi]

--------------------------------------------------------------------------------
Originally posted by Max Habibi:
I'm surprised that you would think that [the requirements strongly steer us in the direction of building an equally business-agnostic generic database server]: maybe you had a different version of the test then the most recent version.
--------------------------------------------------------------------------------

I did, and it had a much stronger emphasis on re-use than the current one (to the point of explicitly stating that the database stuff was going to be re-used in the future), which might colour my thinking.

Quite Frankly, I think it colors your thinking more than you realize. As the assignment evolved, reuse is no longer mentioned. I was involved with the beta for scjd 1.4, and it was not mentioned there either. I will grant that, if reuse is an core feature, then your solution, from the generic nature of Data to the Unrefenced, seems more plausible.

But regardless of that: (1) Data is fully generic.

yes. However, the exam clearly states that modifying it is acceptable.

(2) The Data API is the API of a fully generic database.

yes.

(3) You are strongly steered towards exposing your database server using the Data API.

Not at all true. Where are you so steered? How is this accomplished? Where in the instructions does this steering happen? Are you simply going to point back to 1 and 2?

Now if the stuff you're writing is just for the FBN client, the design you're being forced into makes no good sense whatsoever.

This is not a clear sentence. Which design? Who's forcing? The instructions? Me?

That, together with the evident genericity and reusability of the Data class itself, seems highly significant.

Only if you're predisposed to that opinion. It does not seem 'highly' significant to me,

quote:
--------------------------------------------------------------------------------
There are no 'applications': only a single application. Writing code for non existing applications increases complexity, which is the exact opposite of the directive the students are given here. [...] You're not a consultant who's creating a shrink wrapped product that you can then turn around and sell to another client.
--------------------------------------------------------------------------------
This is rather a distortion of the point I'm trying to make.

No, unless you mistyped, I read you to say applications, as in the plural. There are none, there is only the Fly by Night application.

I'm still totally stumped how you can possibly argue that better reusability is not a nice-to-have. It is always a nice to have; even when you decide that the extra effort isn't worth it, that it's not quite nice enough to justify the price, that doesn't make it any less of a nice-to-have.

This is a distortion of my point. I'm arguing that there are no compelling reasons to think that mapping multiple locks to a single client will ever be of benefit to the client. To be fair, there is no compelling reason to think that it will not. Your assertions that it 'might', at some future point, become so, is an unproven one. The same could be said about forcing each Client to hold a single record. We simply don't know, thus it's foolish to say that things 'must' be this way or that/

Specifically, if introducing an (in this context) unimportant restriction greatly simplifies matters, go for it ...In this case, it has none of these. To the contrary.

Well, since we haven't gotten to that point, it seems irregular make predictions on what we will find there. For right now, lets agree that there is some disagreement over the issue of mapping locks to clients providing benefit.

quote:
--------------------------------------------------------------------------------
The javadoc does not even hint at pink elephants dancing around the border, or an interface for the deaf. However, a good developer will choose to exclude those also, because they do not serve a business function, per the specifications
--------------------------------------------------------------------------------
Very funny, or silly,depending on how you look at it.

Peter, it would be height of rudness for me dismiss your arguments as being silly.

To my memory, the assignment supplies no javadoc for either pink elephants or interfaces for the deaf. There is, however, a javadoc specification for the lock() and unlock() functions, and it provides essential instructions for the assignment (e.g. the whole client ID issue). If you do not think that this same javadoc should clearly document restrictions on the number of locks that can be held, I will never want to use or maintain your software!

I probably wouldn't hire you

If, on the other hand, you think that modifying the supplied contract in the interest of simplicity is OK,

When have I ever said this?

Your position is just not consistent, Max, and in the light of that,

To me, this implies that you're not paying careful attention. When have I ever implied that the assignment specs should not be adhering to?

turning what I'm saying into idiocy with elephants isn't the most convincing of responses.

Nonsense. I exaggerated to bring your point out into the light. Said point being, you are designing for non existent requirements, that is fine, but lets acknowledge it.

Please give a clear answer: is it OK to modify the supplied contract (as described by the javadoc) if the modifications work for FBN and it makes things lots simpler, or isn't it? If it is, then why not remove the whole client-ID business? If it isn't, then what's this number-of-locks-restriction business about?

Again, nonsense. this is where I think your confusion starts. There us no requirement regarding the number of locks a client can hold. What part of this is unclear? And again, I have ever said that you should follow the directions to the letter.

quote:
--------------------------------------------------------------------------------
Saying that the inverted map is an 'excellent' and 'faithful' representation of the problem does not make it so, as I'm sure that someone with your skill in discussion is aware. You have presented arguments about why you feel that it is an excellent reason: they have been answered.
--------------------------------------------------------------------------------
They have never been answered;

Of course they have, as you can see by read back on this tread. Your appeals to Set theory did nothing more then drag the argument to a remote, but defendable spot. The problem being, that you were discoursing on the best way to map many to one. Since it is not proven that this something we need to do, it was as wasted, and districting, exercise. Please, stick to point. First establish that there is a requirement that we map many to one, then talk about the best way to do so.

...Core problem domain constraints like "you can give a record lock only to one client at a time", "the locked records form a Set", "there is no a priori reason why a client cannot hold more than one lock" are fully expressed with the map in one direction and not at all with the map in the other direction. Fact.

Irrelevant fact, since we do not need such for this application.

--------------------------------------------------------------------------------
[...] this generic nature is 1) unspecified in the requirements, and 2) requires more work, and 3) complicates locking (which assertion I have not proven yet)
--------------------------------------------------------------------------------
You haven't proven item 2) either -- and won't ever be able to, since it doesn't require more work.

Well, since I don't believe in psychics, I will try anyway . Will you agree that writing more code is more work? Yes or no?

It's a pity that we aren't able to post code here because it would help make things pretty obvious.

Why not? I have posted code, and you are welcome to(so long as it doesn't give away any real answers)

Regarding 1), well, no good developer needs encouragement when it becomes clear that an implementation can be made more generic with no extra effort.

Nor does any good developer need discouragement when making code generic creates more code and does cost extra effort.

--------------------------------------------------------------------------------
"That is the underlying cause which gives rise to this restriction; you're trying to shoehorn a square problem"
Peter, I expect better from you. I specfically restarted this thread, because I wanted us to focus on the merits of the arguments, and not on the suspected motivations of the fellow we're discussing this topic with. As the moderator of this forum, I'm making this a ground rule. Thus, no more 'you are trying to', etc.

--------------------------------------------------------------------------------
I was looking for an analogy to describe the mismatch between problem and solution if you do the map the wrong way around;

Well, the problem here is that you have to establish that it is the 'wrong' way around, which has not been done. again, simply repeating it is not sufficient.

I'm not conscious of ascribing specific motivations to you. However, if this offended, then please accept my apologies.

I'm just suggesting that you stick the facts, and not to 'motivations' behind them.
quote:
--------------------------------------------------------------------------------
Demonstrate, and argue on the merits. If you can prove that locking multiple locks per clients is the only reasonable choice, then please do so.
--------------------------------------------------------------------------------

I'm not trying to argue that "locking multiple locks per clients is the only reasonable choice" in isolation. As I said, it is merely one symptom of a deeper issue: how do I model my problem using a Map? I have demonstrated why, quite extensively, as I remember. For example, I even dragged set theory into it to show that the problem fits the map in one way only. There has been nothing to refute it.
- Peter

it hasn't been refuted Peter, since it address a problem we do not have. You appeals to Set theory non withstanding. You are, in fact, ascribing solutions, and justifying, without first establishing that there is a problem. That's not good engineering.
M
[ March 20, 2003: Message edited by: Max Habibi ]
[ March 21, 2003: Message edited by: Max Habibi ]