Should lock methods be callable by the client

[Ken Krebs]

Here's my 2 cents worth.
I have chosen the 3-tier approach because it is a very bad practice to make the correct operation of a server depend upon correct implementation of Client/Presentation layer code. A simple example of this is that in well behaved servers, validation always should take place at the server regardless of whether some preliminary validation is provided within a client.
Although a client cannot always be prevented from entering bad data into a database, under NO circumstances should a badly written client be allowed to corrupt a database or make it inconsistent. As near as I can tell, in my test, the purpose of the locking functionality is to prevent multiple client threads from screwing up the database during a delete or update operation. Therefore, in my test, I have implemented all locking within my Business Logic layer which is the only client of the Persistence layer.
The lock/unlock methods appear to me to represent a transactional boundary (Unit of Work pattern) that is best accesed by a Business objecs that then accesses the component(s) in the Persistence/Data Access layer in an appropriate way. For example, if the test was a Banking application and you were implementing a money transfer, you would withdraw money from account and put it in another within a single tranactional boundary, typically in one of your Business objects.
It seeems to me that since part of the test is to determine the developer's ability to think through how best to solve the problem given an incomplete and possibly faulty spec, the developer should do what is correct even if the spec ambiguously suggests doing the wrong thing. You can still come up with a correct implementation doing the locking on the client side but it is still a bad design IMO. I think it is far more risky to take this approach than to challenge an ambiguous and possibly faulty spec by doing it correctly.
It is hard to tell what to expect from the Sun testers as the test itself is a moving target and they do not give feedback on markdowns only on failures. The test designers at Sun are truly sly in the way they have done this and are to be commended for this as it upholds the value of the certification. I think this certifcation is by far the best of the bunch as there is no ability to rely on rote memorization. The only unrealistic aspects are the lack of being able to clarify the spec and the lack of a deadline but this is good tradeoff IMO. Hopefully they will come up with one for J2EE that is just as good and does not force one to simply regurgitate a bunch of dogma about how wonderful Entity Beans are :=).
BTW, I have not yet submitted my test, although I am very close, so I can't give concrete feedback on this.
kktec
SCJP1.4 & SCWCD

[Tony Collins]

Good post.
Tony

[Philippe Maquet]

Excellent post, Ken !
New updated ratings :

2-tiers : 40%

3 tiers : 60%

Best,
Phil.

[Andrew Monkhouse]

Hi Ken,

Although a client cannot always be prevented from entering bad data into a database, under NO circumstances should a badly written client be allowed to corrupt a database or make it inconsistent.

Agreed. But a properly designed 2 tier system will not allow a badly written client (or even a malicious client) to corrupt the database.

The lock/unlock methods appear to me to represent a transactional boundary (Unit of Work pattern) that is best accesed by a Business objecs that then accesses the component(s) in the Persistence/Data Access layer in an appropriate way. For example, if the test was a Banking application and you were implementing a money transfer, you would withdraw money from account and put it in another within a single tranactional boundary, typically in one of your Business objects.

I have a problem with this as well. The people talking about three tier systems are not really building three tier systems. There are two systems: the client and the server. You might be breaking your server system into two distinct parts (I wonder though, how many of you are really designing clear separation into your "three tier system"), but at the end of the day, it is one server application.
And this, to me, could cause a potential problem in the future if any enhancements are required. When the enhancement goes live, the entire server has to be replaced. No other option. In your example of the banking system, say right now all we allow for is debits. To add a credit facility, you would have to build new business methods to handle it on the server side, then take the entire server out of operation while you put the new one in.
With the "two tier" system, there is no such problem. You already have the "lock", "modify" etc., methods available to the next tier. So all that is required is a modification to the next tier, which could be distributed to clients gradually.

You can still come up with a correct implementation doing the locking on the client side but it is still a bad design IMO.

But it is the client's choice.

I think it is far more risky to take this approach than to challenge an ambiguous and possibly faulty spec by doing it correctly.

I don't agree that this is ambiguous. I think the "server must provide locking" statement is clearly not "the server must use locking".
So it is not a case of "doing it correctly". What you are suggesting is to do it "in a way that you think is better than that requested by the customer".
If we were able to discuss this with the client, then suggesting the better way is definately a great thing. But since we cannot, then I think we should be doing what they asked.
Imagine if you were working in a clothing shop, and a person asked you to order some clothes (handing you a list) and walked out. You look at the list and see that the clothes are three sizes too small for the person that just walked out. What do you do? As far as I am concerned, I have in writing what the customer wanted, and I cannot verify it with them since they have already left, so I would order exactly what they asked for, and if it does turn out to be wrong, I have the customer's written instructions, and the position that I was not able to verify with the customer. You are suggesting that you would ignore their written request and order the size that you think is right for them. But what happens in your case if the person was ordering the clothes for their child as a gift? Now you are in trouble for not meeting their written request. You have no fallback position.
Regards, Andrew

[Philippe Maquet]

Hi Andrew,
Although you didn't reply to Michael's post and to mine just below, you still seem to assert("provides" == "exposes to clients"). Were my arguments about it not valuable (the server providing a GUI, the server providing other functionalities which are not exposed to clients) ?
The way we interpret the word "provide" is the key point, because the only important question in this thread is "Is the 2-tiers design required by the instructions ?", and not (as Jim wrote it) "Is 3-tiers better than 2-tiers ?".
Thanks to reply to this "provide" question.
Best,
Phil.
[ September 28, 2003: Message edited by: Philippe Maquet ]

[Andrew Monkhouse]

Hi Philippe,
Sorry, I didn't mean to ignore your/Michael's comments.
I believe that "provide" means "supply" - and it has to supply it to someone. When it provides something, there has to be a reason why people want that provided thing.
I think the big difference here is one of "use" versus "supply". A car uses petrol. It provides trasportation. Your database uses locking. It provides a safe update facility.
I was looking at your examples where you were trying to explain providing something, but not to the client, and I don't think your examples achieved this.

If 80% of a server job is to serve clients requests through an exposed interface, my server also provides a GUI to let an administrator manage application, network and database settings. It provides functionalities which are not under clients control : database caching, "live" backup, lock timeouts, broadcasting of messages, database opening and shutdown, etc.

Your server provides the GUI to the administrator (external to the server).
Your server provides a cached database to the clients. The fact that they cannot configure it does not mean that they are not provided with it. The fact that your internal processes also use it does not alter the fact that it is provided to the clients.
Live backups is a feature being provided to clients: they do not have scheduled outages due to the database being offline. Take the clients out of the equation - what is the benefit of a live backup? In fact if the clients continuous access requirement is taken out of the equation, live backups are undesirable.
Lock timeouts is another feature being provided to clients. As a client, I do not have to worry that because my client program just crashed the record I had locked will not be accessible until the server is restarted. Take away the client's need for this, and who cares if a lock ever times out?
I don't understand what "broadcasting of messages" means to you, so I am not sure about this. But I would have to ask who are you broadcasting messages to?
And for "database opening and shutdown" - I don't believe that the server "provides" that to anyone. If I was looking at a marketing statement on why I should use your server instead of Jim's, I would accept all the other points you mentioned as being good things for the server to provide. But I would not expect to see "database opening and shutdown". To me, this is an internal function of the database, and should not be mentioned.
However your server's main class might provide an open database connection to the server's caching class (I doubt it, but this is just an example). So it is an internal part of your server providing the "database opening" to another internal part of the server. In both cases it is internal parts. The server as a whole is not providing it.
---
Now, if I had to write a functional requirement that allowed for the business methods on the server, I would not write "provides locking". I would write something along the lines of "provides guaranteed safe updates where a record cannot be updated twice" or something along those lines.
Regards, Andrew

[Michael Fitzmaurice]

Hi Andrew
Again, I see that interpretation and perspective regarding the word 'provide' is the all important issue here. This is especially apparent from your most recent post, where you say

Your server provides a cached database to the clients. The fact that they cannot configure it does not mean that they are not provided with it. The fact that your internal processes also use it does not alter the fact that it is provided to the clients.

You see this is being an argument *for* your own interpretation, whereas I see this as an argument *against* it. My own opinion is that this is the same situation as the locking mechanism in my data layer - the fact that the clients cannot use it directly at the lowest level does not mean that it has not been *provided* for them (note I said *for* them, rather than *to* them. Perhaps if Sun had appended one of these 2 words to that contentious sentence, we would not be having these discussions...).
I am by no means any kind of database expert, but it seems to me that if I write some client-side JDBC code to call a stored procedure on a commercial database server, I do not need to have locking at the row, page, or table level exposed to me (I know in SQL Server, for example, you can provide locking 'hints' in your T-SQL, but the server can choose to ignore them, rather like a JVM may choose to ignore calls to System.gc()).
The server handles lock contention and management transparently to my client and makes sure (at least to the degree specified by my configuration of the transaction isolation level) I cannot destroy the integrity of the data. In this way, I see the DB server as *providing* lock management functionality for my client. The client cannot tell the server what to lock, when, and in what order, but relies on the server to know how to do all that.
I must also stress again that for my money, I am not ignoring the spec because I don't like the architecture it suggests. I feel I am actually providing software as specified, and that the 'written instructions' you talk about actually support my case. Its not a question of the customer/Sun pointing to the spec and saying 'there - you didn't do that' and me replying 'no I didn't, because that is a stupid requirement, you Dunderhead...'. My reply would be 'Yes, I did fulfill that requirement (you Dunderhead...). In what way do you think I didn't?'.
At that point, I would expect a furious row concerning the meaning of the word 'provide' to break out, probably culminating in physical violence (where's that chop socky expert Habibi when you need him...?). However, as Phil said, this is just as likely to happen to members of the other camp as it is to the Guinea pigs, in my opinion. It all depends on the customer/Sun having the same interpretation of the word 'provide' that the developer had.
So, not unlike the real World after all...

[Yuan Ye]

Hi, My understanding of "provide" is just the same "implement". It doesn't necessary mean to "provide to who", it can be "provide to itself". I wonder if Sun provide any spec in some other languages? ex. Chinese. I remember there are language choice when doing the SCJP.

[Philippe Maquet]

Hi Andrew,
Thanks for your reply.
As Michael, I think the arguments you develop in your last post reinforce our interpretation, not yours.
I presented all my examples you quote in your last post with this introductory words : "It (the server) provides functionalities which are not under clients control".
While the important words were "not under clients control", you proved that those functionalities are aimed to clients benefit, but the latter is obvious IMO.
Server/Clients relationships are like Supplier/Customers ones.
As I tried to prove that "provide" != "expose to clients", and as functionalities "exposed to clients" are, by definition, "under clients control", I think that I proved that "provide" != "expose to clients", by enumerating a few functionalities which are never "under clients control" ... QED.
Best,
Phil.

[Andrew Monkhouse]

Hi Michael & Philippe,
I still believe that your "server" is not "providing" the locking. Some component of your server is providing locking to some other component of your server. But your "server" as a stand alone application is not providing locking - it is using locking.
From the client's point of view, there is no visibility of this locking. In fact you could develop a safe server application without locking since you are using the business methods. Your server is providing a safe update process.
Michael, your explanation of calling a stored procedure is a good one. But the difference with that is that you can update the database both ways - you can call the stored procedure, or you can access the database directly, and use the implicit or explicit locking and/or transactions that the database provides.
I think I am going to have to accept that this is a difference of opinion. I can see the points in your argument, but I don't agree with them, and I don't think I can phrase my arguments any differently or produce new arguments at present.
And despite my convictions, I don't believe that you will fail - as I said in my opening message, I know people who have passed who have only provided business methods.
Thanks for the great discussion guys.
Regards, Andrew

[Jim Yingst]

Note that while the discussion does indeed center around the interpretation of the word "provide", it's not just the fact that they said "provide", but also the fact that they referred to a specific interface. This strenghtens my perception that they're telling us to expose that method to the client, exactly as specified. If they were just talking about internal implementaion details, that really shouldn't be part of requirements anyway. If a customer gives me requirements and specifies an interface, I'm strongly inclined to assume that they want that interface to be the external interface. What the server does internally is none of their business.
Anyway, this probably is just an "agree to disagree" thing; we all must make our own choices, and like Andrew I agree that if you don't expose the locking, your score will probably be unaffected. But we still want to obey the specs, an the customer's intent, as well as we can. I look at "Your server ... must provide locking functionality as specified in the [provided] interface"" and my gut feeling is still that it's about 80% likely that what the author meant was that the server must provide this method to the client, using the specified interface. Yes, it's possible to interpret this differently, and justify it, but I still have to go with what I think they meant. Provided this does not lead to a completely unworkable design, which it doesn't. It's just a less robust design than might have otherwise been possible. And as I noted earlier, there may be legitimate reasons why the customer really needs the lock API exposed; we just haven't been told what they are.
Anyway, I could go on, but I think all the important points have been made; we just need to pick the interpretation that makes the most sense to us individually, and go with that. Cheers...

[Philippe Maquet]

Hi Jim,

Yes, it's possible to interpret this differently, and justify it.

That's what I hoped you or Andrew finally would write ! Thanks.
Anyway, this thread finished to destabilize me. I decided to get SCWCD before SCJD.
I've done 75% of the whole job (database, network framework through sockets, server GUI), but reading this thread, and so many others (no relation with this one) where "Keep it simple or you'll fail" can be read under the lines, I lost all self-confidence about my ability to win this test. So I'll stop here, get SCWCD, and come back to finish the SCJD job when my self-confidence will come back.
Best,
Phil.
[ September 29, 2003: Message edited by: Philippe Maquet ]

[Bharat Ruparel]

Hey Phil,
Take it easy! You are almost there.
Bharat

[Jim Yingst]

No!!! Don't quit now. Get the real certification first.
Regarding this thread, I don't think the concerns of Andrew and me are sufficient to warrant redesigning things at this point - they're relevant to people who are still in the initial design mode, but I don't think it's worth tossing out your existing design.
As for "keep it simple" - well, simplicity is a virtue. But I think that big questions are: does your code work correctly? And can a junior programmer look at the individual parts and understand how they work? It's possible to write code that was complex to put together in the first place, but is still easy to understand and maintain. If the various complex bits do server some useful purpose, and are well-factored to be no more complex than necessary to server that purpose, then I think you'll be fine. OTOH if somethign doesn't work correctly, that's when you lose points big time for complexity.
Well, I don't really want to undermine the "keep it simple" message too much - but don't make any abslute decisions at this point. Go home, have a few beers, see how you feel in a few more days. I'm quite confident that you can produce an excellent submission for the assignment. Cheer up...

[Vlad Rabkin]

Hi Phil,

Anyway, this thread finished to destabilize me. I decided to get SCWCD before SCJD.

WOW! I thought it is impossible!!! Andrew, Jim my great respect to you
I gave up everything: ReadWriteLock, Record-Level Locking, Multi-threaded client. You were one of few who were strong enought. Don't give up!
Best,
Vlad

[Philippe Maquet]

Hi Jim,

No!!! Don't quit now. Get the real certification first.

I don't quit, I just intend to get the fake certification first, and then come back to this one. Promised ! (BTW, seeing my current URLyBird code base, it would be quite silly not to finish it and get certified).

but I don't think it's worth tossing out your existing design.

I never thought about it (because 3-tiers is better), but well to expose DBAccess "just in case it's needed". It's easy to do, but just more job (especially when you chose sockets) and more to be documented.
My problem is that I am far too much perfectionist : never happy with what I've just done if it's not "perfect" to me.
Just two examples :
1) Do you remember our discussion about findByCriteria(), where fields may be indexed (or not) ? I search on indexed fields first, ordered descending by key occourrences (to make it understandable, let's say that if you decided to index the "smoking" and "location" fields and that both are concerned by your search criteria, "location" probably will be used first). Indexes are used one after the other using retainAll() on a recordset. Well, writing that code, I asked myself : "If there is only 1, 2, 3 or even 10 records in a given temporary result set, does it make sense to use the next indexes, or is it better to perform further a linear search (with all remaining criteria combined) ?". As it's a no-answer-question, I added a property that I called "sequentialSearchThreshold" (default = 10) which fixes it. OK, simple. Now I am writing the server GUI. Do I need to publish it ? If not, did it make sense to make it a variable ? If I make that property public (through the GUI), how to explain its use in the user guide ?! Do you see the traps where I am falling in ?
2) I promised to myself "Phil, for the GUI part, think to Mark's advices, keep it simple !". Mmh, I am just done with the server-side GUI and ... it's all but simple. Under the tab "Settings" I have three sub-tabs ("Application", "Network" and "Database"). And for each one, just the properties I need :

Network : IP Address, Listen Port, Receive Buffer Size, Send Buffer Size, Max. Nbr of Connections, Min. Nbr of Handlers and Max Nbr of Handlers

Database : Database File Name, Cache All (checkBox), Max. Cache Size (grayed out if Cache All is checked), and Indexed Fields (string of comma-separated fields).

Where (IMO) do I "too much" in that server GUI ? In the network settings, why an IP address ? I just noticed that's it's possible for a given machine to have more that one IP adress. So you may choose it in a nice ComboBox where you find "127.0.0.1" + all the IP adresses of the host machine. Nice, but probably too much for the assignment. Database settings : the database file name and the index fields string have something common : by clicking on the dotted small button on the right side of the JTextField, you get a dialog. Why did I need to abstract it this way, using 3 classes and 4 interfaces ?
Class JValidatedTextField extends JTextField
interface TextFieldValidator
class JDialogField extends JComponent (building one JValidatedTextField + one JBrowseButton of my own (private class)
interface DialogExecutor
interface Filevalidator
interface DBFilevalidator extends FileValidator
class JFileTextField extends JDialogField
And why, just instantiating the JDialogField used to get the indexed fields from the user, looks like this ?!

        indexedFields = (JDialogField) addControl(new JDialogField(
            new TextFieldValidator() {
            public boolean isValid(String text, boolean showMessage) {
                boolean retVal = true;
                initFieldsListIfNeeded();
                StringTokenizer tok = new StringTokenizer(text, ",", false);
                while (tok.hasMoreTokens()) {
                    String fieldName = tok.nextToken().trim();
                    int index = -1;
                    for (int i = 0; i < fieldNames.length; i++) {
                        if (fieldNames[i].equals(fieldName)) {
                            index = i;
                            break;
                        }
                    }
                    if (index == -1) {
                        retVal = false;
                        if (showMessage) {
                            JOptionPane.showMessageDialog(thisInstance,
                                "Field \"" + fieldName + "\" does not exist.",
                                "Invalid Field Name", JOptionPane.ERROR_MESSAGE);
                        }
                        break;
                    }
                }
                return retVal;
            }
        }
        ,
            new DialogExecutor() {
            public boolean execute(JValidatedTextField textFiled) {
                initFieldsListIfNeeded();
                fieldNamesDialog.initFieldsList(fieldNames);
                fieldNamesDialog.setFieldNames(indexedFields.getTextField().
                                               getText());
                return fieldNamesDialog.showDialog();
            }
            public String getText() {
                return fieldNamesDialog.getFieldNames();
            }
        }
        ,
            "Build"
            ),
            DIALOG_FIELD_WIDTH);

I should go and sleep, because tomorrow is another day !
Best,
Phil.
[ September 29, 2003: Message edited by: Philippe Maquet ]

[Philippe Maquet]

Hi Vlad,

Don't give up!

Thanks for your support (same for Jim and Bharat BTW). I won't give up, just get SCWCD before SCJD. Two weeks ?
Best,
Phil.
PS: I shouldn't write it, but I really appreciated your friendship (Bharat, Jim, Vlad). When you get depressed (a bit), it's just nice to be gently boosted by people like you. Thanks.

[Andrew Monkhouse]

Hi Philippe,
I just wanted to add my voice to those crying for you not to leave your SCJD assignment. You have some really excellent ideas, and I have no doubt that you will pass. It's great having you in this forum.
But I can understand the need to take a break - I remember when I submitted my assignment, I got to the point where I had to submit I was just so sick of working with it
Good luck with the SCWCD.
Regards, Andrew

[Philippe Maquet]

Thanks, Andrew.

But I can understand the need to take a break

That's exactly that, but a little more too. I have been far too slow in this SCJD assignment (anyway in comparison with what I expected). In the meantime, there is no "visible" return, for me (except more java experience of course and I have no regret in that area), but above all for my entourage. Getting SCWCD quite fast could ligthen the pressure a bit ...
Best,

Phil.

[Arun Kumar]

Phil,
Hope you will be back after your SCWCD. I should have done what you are doing now. But i took my SCWCD before taking SCJD. Now i cant wait to finish this and submit it and move on to SCBCD. I should have taken SCWCD as a break during the SCJD certification
Cheers
Arun

[Chris Harris]

Hi all,
First Phil good luck with you SCWCD, hope to see you back soon. I have only been here a little while and you have already provided me with a lot of useful advice.
My plan was to write a 3-tier solution, however after reading this thread you have put this into question. For the requirement I would say that Sun are asking for a 2-tier solution. The main reason to go for 3-tier is because it provides a better overall system design.
But if Sun were failing people for writing a 3-tier solution it would be all over this forum.

Chris

[Andrew Monkhouse]

Hi Chris,

But if Sun were failing people for writing a 3-tier solution it would be all over this forum.

As I have said a few times, I don't believe anyone has failed for only having business methods exposed to the client instead of the methods of the provided interface. I would even go further - I haven't seen anyone loose marks that we could attribute to them only exposing business methods.
And as Michael & Phil have ably pointed out, the instructions could be interpreted to allow for the three tier solution.
So the issue comes down to what you believe the instructions are asking for, and what you are willing to justify in your submission. If you believe that the instructions are asking for a two tier solution and you deliver a three tier solution, then you will have a hard time justifying it, which could cause you problems.
Regards, Andrew

[Philippe Maquet]

Hi Arun and Chris,

Hope you will be back after your SCWCD

hope to see you back soon

Just to make things clear (but maybe you noticed it already), I don't quit this forum ! I just take a break in coding my assignment, studying a bit SCWCD in the meantime.
Best,
Phil.

[Andrew Monkhouse]

Hi Phil
I'm sure your only hanging around in case I try to declare victory
Regards, Andrew

[Philippe Maquet]

Exactly !

[ulvi ugur]

Hi All,
Guys, all technical discussions aside, let me remind you something about this assignment :
The whole point of this assignment is being in this discussion and increasing increasing cons and pros of different alternatives (thus the specs are quite vague)
and may be another thing For Sun it is important that these people put so much effort. If you know what you are doing and why you are doing, thats all they care. I don't want to think the opposite.
and may be a last thing Sun WANTS you to get this certificate
My comment was a bit philosophical, I know, but it sometime helps to look at the whole picture.

[Tony Collins]

Well I lost alot of marks on my locking strategy, so maybe the 2 tier gang are right.
Amazingly my project got marked in 3 days.
Tony

[Sudhansu Pati]

Hi all,
Lot of discussions happened while I was at sleep. Here is another recommendation.
1. use a class called DBConnector() which can be directly called by GUI. DBConnector()can return either a local DBAdapter() or remote DBService().
[DBservice has all client-aware business methods and DBAdapter implements DBservice]
2. I think DBAdapter() should be in a separate package like suncertify.middletier
3. The client jar file should include the suncertify.middletier package as well.
4. I think the easiest way to implement the bookContractor() method is to change the update(int RecNo, String[] data, long lockCookie) method in Data.java to include the book logic. The logic can be.
// check if already existing record's owner field != null;
// if records owner field !=null throw AlreadyBookedException()
Lets take an example of bookContractor()which looks as follows.
bokContractor(recNo){
lock();
//write code
update();
unlock();
}
Now lets assume that 2 clients call the bookContractor() method at the same time. The sequence of operartions may be as follows.
1. client1 enters the bookContractor(recNo) method.
2. client2 enters the bookContractor(recNo) method.
3. client1 calls lock(recNo) method.
4. client2 waits because recNo is already locked by client1.
5. client1 calls update() method and either updates a record or thorws exception.
6. client2 is still waiting.
7. client1 calls unlock method in either case (successful update or exception)
8. client2 comes out of while(lockedRecord.hasKey(recNo)){lockedRecords.wait()} loop and acquires lock.
9. client2 calls update() method and throws AlredyBooked() exception.
The only problem with my approach is, both clients first see that the contrcator is available but one of them gets dissappointed for not being able to book it. I think this is same as buying stuff from ebay. only one item is available and 2 buyers try to buy at the same time, only one can get it.
IMO, We can write that in our documentation and it is perfectly understandable. Some of the greedy clients may hit their head all day long for not clicking the mouse button before somebody else did and losing the commision(for not making the same), but that again will create anxity to work smarter and faster to book the contractors as soon as they can and as fast as they can and make most efficient use of our software.
Any comments ??

[Dushy Inguva]

Hi Bharat,
Nothing could make me more happy than to findout that Sun is not biased towards the Two Tier model for the exam (well.. if i win a million $.. it can make me more happier !!!)
But after Tony's result, im skeptic about taking the three tier approach.
Dushy

[Chris Harris]

Well done Tony
Can we be 100% sure that you lost marks because you took a 3-teir approach?

Chris
[ October 04, 2003: Message edited by: Chris Harris ]

[Jim Yingst]

Can we be 100% sure that you lost marks because you took a 3-teir approach?
No. He lost points for something related to locking, but we don't ahve a way to know what, exactly. Maybe there was some subtle bug which he overlooked. Or maybe Sun considered the 3-tier design overly complex. Or maybe the grader was just in a bad mood. Well, probably not the last one. But we'll never know for sure. If someone manages to get 100% with a 3-tier approach, that would tell us something more definite. (Unless their instructions are subtly different.) Or if we collect enough info from people and find that most people who do 3-tier score worse than most people who do 3-tier, that might tell us something. But right now Tony is just one data point, signalling Sun may object to 3-tier; maybe not.

[Vlad Rabkin]

Hi,
Jim:

 
Can we be 100% sure that you lost marks because you took a 3-teir approach?

NO! I totally agree with Jim.
We need one more "Guinea pig" for confirmation...

.. Just a joke.
Tony, one more time, greate respect for your challenge and Congrats!
Best,
Vlad

[Bharat Ruparel]

Hello Dushyant,
You wrote:

Hi Bharat,
Nothing could make me more happy than to findout that Sun is not biased towards the Two Tier model for the exam (well.. if i win a million $.. it can make me more happier !!!)
But after Tony's result, im skeptic about taking the three tier approach.

Me too! May be I will go the other way, i.e., with Client side locking. That way the group will have two sample points. I hate being a statistic more that statistics.
I have some distance to go before submission though.
Regards.
Bharat

[Tony Collins]

Yeah it could be anything, but I had very thorough testing for my locking mechanism and I would have failed if it contained a bug. It was sugested to me that I may have lost marks for not providing unbook functionality.
Tony

[Chris Harris]

Hi all,
How about creating a new package for the middle teir i.e suncertify.mid. This will contain the DBAdapater and DBClient interface.
Doing this allows the database to provide locking methods and still hidding the locking methods from the client. What do you all think? Is this over complicating something that would be every simple.
Thanks
Chris

[Sudhansu Pati]

[B]How about creating a new package for the middle teir i.e suncertify.mid. This will contain the DBAdapater and DBClient interface.
[B]
I am planning to do the same. I thought of using suncertify.midtier as the package name. I am looking for a better name.
Do you have something called suncertify.network ? Where do you put your DBConnector, DBremote and DBImpl ?
I am thinking of 4 packages at my end.
suncertify.db
suncertify.midtier
suncertify.network
suncertify.client
The client jar will contain all files from suncertify.client, some files from suncertify.network and all files from suncertify.midtier.
The server jar will contain all files from suncertify.db, all files from suncertify.midtier and all files from suncertify.network.

[Chris Harris]

hi Suds,
Sounds like I are doing something similar to you. I have the packages:
suncertify.db (We all have to have that one )
suncertify.mid (The business tier)
suncertify.comms (A package containing RMI code to communicate between the gui and the mid)
suncertify.gui (The gui for the client)
I am trying to make it as simple as possible. Similar to that in Max's book.
Chris

[Dushy Inguva]

Tony,

It was sugested to me that I may have lost marks for not providing unbook functionality. - Tony

Do you think we have to provide un-book functionality?
1. Its not an obvious part of the requirements.
2. To unbook, we need the unique id (probably the record id) to be able to un-book the reservations.
3. The method signatures don't suggest an unbook functionality being expected. (The unused delete method is present though).
I could be wrong in my interpretation of the requirements !!!
Thanks
Dushy

[Jim Yingst]

[TC]: It was sugested to me that I may have lost marks for not providing unbook functionality.
Interesting - by whom? Someone with some sort of inside knowledge? Personally I am providing this functionality, but have doubts about it on the other end - is it a good idea?
[DI]: Do you think we have to provide un-book functionality?
I very much doubt you have to.
1. Its not an obvious part of the requirements.
Agreed.
2. To unbook, we need the unique id (probably the record id) to be able to un-book the reservations.
Not a problem for me. When a user searches for records, I display all records that match the criteria, booked or not. So to unbook, they just click un the row and say "unbook", and I look up the record number for that row the same as if they'd clicked "book". The remaining operation is very similar to book, just in reverse.

3. The method signatures don't suggest an unbook functionality being expected. (The unused delete method is present though).
The method signatures don't suggest book either. Both would use update(), wouldn't they?
I could be wrong in my interpretation of the requirements !!!
Me too.
One other concern regarding unbooking: It's possible that our emplyer doesn't want users to be able to unbook records. An unscrupulous user could unbook the record booked by someone else, and then book it themselves. This is my biggest concern. However, it's easy to remove the button from the code (easier than it would be to add it), so my decisions.txt file includes notes flagging this as something that the customer may wish to change, and describing how to do so with minimal hassle. I'm not entirely comfortable with this decision, but I can live with it.
I'd be interested in hearing from others on this. My impression is that most people don't include unbook. Has anyone gotten 100% with unbook? Or without unbook, for that matter? I think both should be possible (under my instructions at least) but I'd like to hear if others have more definitive info.

[Jim Yingst]

How about creating a new package for the middle teir i.e suncertify.mid. This will contain the DBAdapater and DBClient interface.
Yes, I that's pretty much what we've been talking about. Most of us have some sort of adapter which wraps low-level method like lock() in higher-level methodslike book() (or something more mid-range, like an update() that implicitly locks & unlocks for you). The question is whether this adapter should be running somewhere on the server (hiding lock() from the client) or somewhere on the client (hiding lock() from the GUI part of the client). We've been calling this 2-tier vs. 3-tier, but I think it's really more like thin client vs fat client. Thin client means you put your adapter on the server ("3-tier") while fat client means the adapter is part of the client ("2-tier"). We'll put Chris down as another vote for thin client/3-tier.