Should lock methods be callable by the client

[Andrew Monkhouse]

Tony: It was sugested to me that I may have lost marks for not providing unbook functionality.
Jim: 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?

Personally I like Suds' proposed update() method he allows an update

if the update contains an owner and the database doesnt

if the update doesnt contain an owner and the database does

Of course if the middle tier is on the server (thin client) then this nice update functionality will be lost

Jim: It's possible that our emplyer doesn't want users to be able to unbook records.

True. Normally I would try and have some level of authentication for any modification methods. But the instructions have the statement "No authentication is required for database access". So I think that your planned "allow it but give an easy modification to disallow it" is probably the best way to handle this.
Regards, Andrew
[ October 09, 2003: Message edited by: Andrew Monkhouse ]

[Sakke Wiik]

Hi,
I started working on URLyBird 1.2.1 and have read this thread. I seem to have a quite different view of the locking mechanism than most of you, or maybe I just haven't spent enough time on the documentation . Some people even says the lockCookie is a stupid requirement doesn't seem stupid at all if you look at the problem in another way.
The common solution here seems to lock a record directly before updates/deletes. Here's my view of the locking:
1. Client1 wants to book a record. Client1 selects a record for update. So the lock is set on the selected record before he starts updating the row.
2. Client2 selects the same record for update, but gets a notification that this record is locked. Client2 understands the situation.
3. Client1 klicks 'book record' after he has modified the data. Now the real update occurs, and the lock is unlocked directly after the real update.
Here's another check that should be added too(using some common sense):
4. Client3 comes in after Client1 has made the update. Client3 selects the same record for update. Since the record has a client id in the "owner"-field (from Client1s update), he will be notified that the record is already booked.
Makes any sense?

[Andrew Monkhouse]

Hi Saw,
Welcome to JavaRanch.
We don't have many rules here, but one we do have is the JavaRanch Official Naming Policy. That policy requires you to have both a first and last name in your displayed name. Could you please change your displayed name to meet this policy? You can change it here
Your concept is interesting. However do you have a requirement for the lock() method to block until the lock is granted? Usually there is some statement similar to "If the specified record is already locked by a different client, the current thread gives up the CPU and consumes no CPU cycles until the record is unlocked". If you do have such a statement, then client 2 will not get notification that the record is currently locked.
That being the case, if client 1 locks the record and then goes out to lunch, client 2 will be blocked until client 1 comes back.

Here's another check that should be added too(using some common sense):
4. Client3 comes in after Client1 has made the update. Client3 selects the same record for update. Since the record has a client id in the "owner"-field (from Client1s update), he will be notified that the record is already booked.

But at what point are you doing this check? I think most people are doing this check at the point of update, but it sounds like you are doing it at the point of locking.
The problem is that locking isn't just for setting the client ID. You might want to lock a record to delete it. Or (although it is not currently required) you might want to lock a record so you can remove an invalid client booking. So the lock method cannot really care about whether the record has already been booked or not. Plus, depending on your lock signature, you might not be able to indicate that the record has been updated.
Regards, Andrew

[Sakke Wiik]

Your concept is interesting. However do you have a requirement for the lock() method to block until the lock is granted? If you do have such a statement, then client 2 will not get notification that the record is currently locked.

Ok got it. So I assume this statement alone ruins my idea. One option less to think about .

[Philippe Maquet]

Hi Jim,

I'd be interested in hearing from others on this. My impression is that most people don't include unbook.

I won't implement Unbook, but well Undo on books. I agree with 1. and 2. above plus what Jim wrote :

One other concern regarding unbooking: It's possible that our employer doesn't want users to be able to unbook records.

It's even probable. OTOH, Undo is a as standard Edit menu item as Cut, Copy and Paste and should be much appreciated.
Jim, I am a bit confused by this sentence of you :

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.

I decided to show only records corresponding to bookable rooms and justify it. Do you see any issue regarding the instructions with that ?
Best,
Phil.

[Vlad Rabkin]

Hi Phil,

I won't implement Unbook, but well Undo on books. I agree with 1. and 2. above plus what Jim wrote

This a last minute travel agency. I have never seen a lastminute agency which allows you to cancel the reservation (whatever you call it unbook or Undo )
If an employer made a mistake by putting a wrong cutomer ID, for example, it is a task of Aministrator (and therefore administrator GUI) to deal with that, which is not part of the assignement.

I decided to show only records corresponding to bookable rooms and justify it. Do you see any issue regarding the instructions with that ?

You want to take challenges every time. What for? It is better to show all records and document this decision (no "last minute offers" is required), than to do last mean search and don't provide what is required: search records that match the criteria regarless other facts and restrictions.
Best,
Vlad

[Jim Yingst]

[Philippe]: I decided to show only records corresponding to bookable rooms and justify it. Do you see any issue regarding the instructions with that?
This is quite possibly a difference in our assignments. I'm on Contractors, version 2.1.1. My instructions require that a user be able to search for all records, or records matching a particular name and/or location. Nothing about whether the record has been booked.
[Vlad]: This a last minute travel agency. I have never seen a lastminute agency which allows you to cancel the reservation (whatever you call it unbook or Undo )
For Contractors, there's nothing about dates at all, and no implication that anything is last-minute. The lack of dates is pretty stupid really, it seems that once a contractor is booked by a customer, they're booked permanently. I thought it reasonable to assume that once a job is complete, the contractor should be made available again for booking. If I had date info, I could compare the booking date with today's date, and react accordingly. But since I don't have any date info, the only way I can see for a record to be made available is if someone comes along and unbooks the record. I'm assuming CSRs know when a job has been completed.

[Nick S Smith]

Just for your info, the old-style exam seems to have the same (bad?) design requirements, although seems to be a bit more explicit about it:
"Writing Data Client
To connect with your server, you should create a client program. This implementation should include a class that implements the same public methods as the suncertify.db.Data class, although it will need different constructors to allow it to support the network configuration."
The Data class is the class containing methods like lock(), unlock(), readRecord() and so on. So I guess they really do want the client to have acces to these
This exam has been around at least a year though - this topic must have been discussed before somewhere?
Nick

[Philippe Maquet]

Hi Vlad,

If an employer made a mistake by putting a wrong cutomer ID, for example, it is a task of Aministrator (and therefore administrator GUI) to deal with that,

or any other mistake (select a wrong hotel, or for the wrong date, etc.). Do you really think that correcting such mistakes should be performed by an administrator of some sort ?

which is not part of the assignement.

Right. But delivering software which is usable for its purpose is our assignment. What do you think of this scenario :
Customer: I'd like to spend the week-end in New York
CSR : (...)
Customer: (...)
CSR : OK, I confirm the booking
CSR : Sorry, but you'll spend the week-end in Washington.
Customer: What happened ? I cannot accept that !
CSR : You'll have to : I made a mistake and the software doesn't allow any correction.

I decided to show only records corresponding to bookable rooms and justify it. Do you see any issue regarding the instructions with that ?
--------------------------------------------------------------------------------
You want to take challenges every time. What for? It is better to show all records and document this decision (no "last minute offers" is required), than to do last mean search and don't provide what is required: search records that match the criteria regarless other facts and restrictions.

It's no special challenge, just the instructions I was given IMO, and I am (was) not speaking about the 48 hours criterium. Instructions.html describe the required functionalities and explain their purpose. Compare these scenarii :
1. Where only bookable rooms are shown (mainly, bookable == not booked yet and (availability date - now) > 0
(= Phil's solution)
Customer: I'd like to spend the week-end in New York
(CSR enters "New York" in the Location combobox and clicks on Search)
(CSR sees an empty result set)
CSR : Sorry, there is no room currently available in New York.
2. Where all records that match the criteria are shown
(= Vlad's solution)
Customer: I'd like to spend the week-end in New York
(CSR enters "New York" in the Location combobox and clicks on Search)
(CSR sees a result set)
CSR : Hey, you're lucky ! I can tell you already, that there are, have been or will be available rooms in New-York...
Customer : Mmh, sounds interesting, but for next week-end ?
CSR : Hold the line please. I have 549 records to check manually ...

Jim:
I'm on Contractors, version 2.1.1.

In URLyBird, a room is booked or not. I know that in FBNS, it was a little more complex (number of available seats). And I don't know Contractors for that aspect.

Jim:
My instructions require that a user be able to search for all records, or records matching a particular name and/or location. Nothing about whether the record has been booked.

I have similar instructions : "It must allow the user to search the data for all records, or for records where the name and/or ...". "Search the data". The question is : what's data (or relevant data) from a CSR perspective ? What will be in the database just after a little year use ? 95% data relevant to a reporting system and 5% relevant to the CSR.
Vlad, I just advocate that in our instructions, the "overview" part is as important as the more "technical" ones. They form a whole instructions set IMO.
Best,
Phil.
[ October 08, 2003: Message edited by: Philippe Maquet ]

[Vlad Rabkin]

Hi Phil,

Vlad, I just advocate that in our instructions, the "overview" part is as important as the more "technical" ones.

Phil, I don't want to say that your desicions are not reasonable. They are! All what I want to say is that IT developer MUST strictly follow the specification and only do what is EXCPLICETLY required.
It is a part of Business Consultant responsibilities to communicate with the customer about businness flow of your application, not yours.
Just other example 1:
You have booked a room in New York. According the travel Agency regulations, you are not allowed to cancel this reservation, but you gave some flowers to the travel agence (she is a very nice woman ) and she cancel this reservation, which prohibits the rules of the agency.
Another example (I don't wish to somebody from us would have such a problem):
You uploaded your assignement, but realized there was a wrong version of it.
May you change something? Nope ...
So, trying to make extras you can breach other requirements.
Let's try this way:
In your case the agent will not be able to cancel reservation and no Administrtor GUI are available. If my boss blames me I will show him specification and proof that not such function was required.
In your case if this agent would cancel the reservation, (which is not allowed) then this agent and you are in trubble
Best,
Vlad

[Philippe Maquet]

Hi Vlad,

Phil, I don't want to say that your desicions are not reasonable. They are! All what I want to say is that IT developer MUST strictly follow the specification and only do what is EXCPLICETLY required.
It is a part of Business Consultant responsibilities to communicate with the customer about businness flow of your application, not yours.

I read a post of Andrew (I cannot find it now) where he explains that the "application overview" part of the assignment is like a business meeting that you would have attend as developer.
Right, it's not our job to write the specs, but if people invited you to attend such a meeting, it's reasonable to think that they expect something of your presence. IMO, you cannot do as if there was no "application overview" section or, compared with the real world, as if you were not present to a business meeting.
Moreover, I try to not forget this part of the instructions :

This document deliberately leaves some issues unspecified, and some problems unraised. Your ability to think through these issues, in the face of realistically imperfect specifications, and come to a tenable solution is something upon which you are being graded.

BTW, does anyone know what the "General Considerations" are in the marking criteria ? It's 100 points, 25% of the total.
Andrew, do you know what they are ?

Marking Criteria
Your work will be evaluated based on the following criteria. The minimum passing score is 320 out of a possible 400 points.
General Considerations (100 points)
Documentation (70 points)
Object-orietned design (30 points)
User Interface (40 points)
Locking (80 points)
Data class (40 points)
Server (40 points)

I only know what they are not : general considerations are neither documentation, nor OO, nor GUI, nor locking-related, nor database-related, nor network-related ... but they weight 100 points.
Best,
Phil.

[Tony Collins]

I think the marker has a quick look at your project, decides on the mark then makes sure the marks for each section add up to that mark.
Tony

[Vlad Rabkin]

Hi Phil,
1. General Considerations is more concern about your technical design decisions, not your skills as travel agent.
2.

if people invited you to attend such a meeting

.
The problem is that Sun didn't invite you for the meeting and all what you have is specification defined during the meeting without you
Best,
Vlad

[Philippe Maquet]

Vlad,
Here is the conclusion : it seems that we have 100% different views about the same thing ... . But reading your point 1. above, along with your last sentence, I finally wonder if we are talking about the same thing at all (language issue ?!).
Best,
Phil.

[Vlad Rabkin]

Hi Phil,

But reading your point 1...

Yes we do.
I consider "documentation" is comments in your code, javadoc and the user guide.
and "general consideration" is choises.txt which is you design desicions: networking, Locking, MVC and so on, which is application design issues, but not any business considerations(like should I provide Undo or not )
Best,
Vlad
P.S. One more though: it is not really only about the assignement. projects I follow always exactly specification (if I don't have contact to the customer) in real projects without showing off with my creativity and fantasy

[Andrew Monkhouse]

Hi Phil,

BTW, does anyone know what the "General Considerations" are in the marking criteria ? It's 100 points, 25% of the total.
Andrew, do you know what they are ?

I don't know what they are. But the JavaRanch SCJD FAQ has a question titled "Has the marking changed between the old assignment and the new assignment?". In that question it shows what the breakdown of points were for "General Considerations" in the old assignment.
The "Coding Standards" is an interesting issue in it's own right - I am tempted to start a new thread just to talk about it. On second thoughts, no - someone else's turn to start theoretical topics if they want to.
Regards, Andrew

[Philippe Maquet]

Hi Nick,

Just for your info, the old-style exam seems to have the same (bad?) design requirements, although seems to be a bit more explicit about it:
"Writing Data Client
To connect with your server, you should create a client program. This implementation should include a class that implements the same public methods as the suncertify.db.Data class, although it will need different constructors to allow it to support the network configuration."
The Data class is the class containing methods like lock(), unlock(), readRecord() and so on. So I guess they really do want the client to have acces to these

I would have written a different deduction : "So I guess they really did want the client to have acces to these.". The fact that that design requirement is not in the instructions anymore could be a clue indicating they prefer a design choice of our own to be done.
Best,
Phil.

[Philippe Maquet]

Hi Andrew,
Thanks for your reply. Now we know this equation :

general_considerations == (40 * ease_of_use + 40 * coding_standards + 20 * clarity_and_maintainability) / 100

I like those 40 points just for ease of use.

The "Coding Standards" is an interesting issue in it's own right - I am tempted to start a new thread just to talk about it. On second thoughts, no - someone else's turn to start theoretical topics if they want to.

Indeed ...
Andrew, the discussion above about what to show on screen in URLyBird (all data or bookable data) is quite important. As you can see, Vlad and I have 100% opposite views and arguments in that area. It would be great if you could tell us (and the posterity ) what are your own thoughts about it. It begins at Vlad's message posted October 07, 2003 04:50 AM.
Best,
Phil.
[ October 09, 2003: Message edited by: Philippe Maquet ]

[Andrew Monkhouse]

Hi Phil,

Andrew, the discussion above about what to show on screen in URLyBird (all data or bookable data) is quite important. As you can see, Vlad and I have 100% opposite views and arguments in that area. It would be great if you could tell us (and the posterity ) what are your own thoughts about it.

You guys really don't need my thoughts - you do well enough on your own. And I don't think my comments are soo valuable :roll: that you will be changing your designs because of it.
By the way - you guys are hijacking my thread which is supposed to be talking about lock methods!
In the assignment I did, I showed records that were unavailable. However the user could not do anything with that record.
I think the GUI has to get the unavailable records. Otherwise you are going to have to do some major rewrites if you later need to do anything with them (such as unbook() them). Then whether you display them or not is a design decision - it can be justified either way.
As to which way I would go - I think I would show them regardless. If they are displayed, then if the customer rings up to ask which room they are booked into (or which contractor is coming out) I can manually go through the displayed records and see which record has the correct customer ID number.
Regards, Andrew

[Philippe Maquet]

Hi Andrew,

And I don't think my comments are soo valuable that you will be changing your designs because of it.

Your comments here were beeetter ("better" pronounced like "soo" ) than valuable : simply great !
I hesitated to provide a check box labeled "Show All Records", but I was looking for any possible good reason for the user to want to see unavailable records. And you just gave me that reason :

If they are displayed, then if the customer rings up to ask which room they are booked into (or which contractor is coming out) I can manually go through the displayed records and see which record has the correct customer ID number.

Thanks !
Now with that check box, I think that I have the best of both solutions.
When you write :

In the assignment I did, I showed records that were unavailable. However the user could not do anything with that record.

you recognize implicitely that unavailable-for-booking records are generally useless (except special cases as the one you mention later). As I mentioned in a previous post, while those unavailable-for-booking records are not numerous there is no issue. But more you'll use the system, more you'll get useless records, and more that check box will be useful.

I think the GUI has to get the unavailable records. Otherwise you are going to have to do some major rewrites if you later need to do anything with them (such as unbook() them). Then whether you display them or not is a design decision - it can be justified either way.

I don't understand what you mean. If you are able to apply some logical filter on a result set to decide which records to display, it should not be more difficult to apply the same filter while building the result set. It's even easier IMO, because you benefit from the db package functionalities. And in either case, if new functionalities in the future need another filter, you'll have to change it, right ? Now, let's say that the average interesting part of data is 10%, I think it's better design (because of better performance at the db and network levels, this with no added complexity) to get from the server just what you need.
Best,
Phil.
[ October 09, 2003: Message edited by: Philippe Maquet ]

[Andrew Monkhouse]

Hi Phil,

Andrew I think the GUI has to get the unavailable records. Otherwise you are going to have to do some major rewrites if you later need to do anything with them (such as unbook() them). Then whether you display them or not is a design decision - it can be justified either way.
Phil I don't understand what you mean.

Sorry I was getting ahead of myself. Those people who prefer the thin client (3 tier) solution could argue that sending the unavailable records is a waste of bandwidth, and they could filter them on the server side. But, as I mentioned above, I don't think this is a good idea, since it will require some major changes to both server and client if a later requirement was to allow for unbook().
Regards, Andrew

[Philippe Maquet]

Hi Andrew,

Andrew
Sorry I was getting ahead of myself. Those people who prefer the thin client (3 tier) solution could argue that sending the unavailable records is a waste of bandwidth, and they could filter them on the server side. But, as I mentioned above, I don't think this is a good idea, since it will require some major changes to both server and client if a later requirement was to allow for unbook().

Sorry Andrew, but I cannot follow you there. The more a client will be thin (a web browser is the thinest possible), the less it will need changes if new functionalities come up.
And thinking of that, I thought of one more argument based on the instructions. Unfortunately, I used it already in a previous post :

Phil
quote:
--------------------------------------------------------------------------------
Instructions:
Your user interface should be designed with the expectation of future functionality enhancements, and it should establish a framework that will support this with minimal disruption to the users when this occurs.
--------------------------------------------------------------------------------
This is probably one of the best parts of the instructions for the 3-tiers advocates : if we decouple the client job from the low-level database job, it's possible to change the db system (to a commercial one like Oracle - quite probable when they'll move to the web) "with minimal disruption to the users when this occurs.". Client code doesn't need to change, and users just need to reconnect to a new server. (BTW, with my sockets implementation which supports call-backs, it can even be done without any disruption to the users at all (by broadcasting a call to a callback method like please_reconnect_to_new_server(newIPAddress, newPort)).

Let me give here some more realistic example. The "search" functionality will be implemented in a way which is 100% server-driven : when connecting to the server, one of the first thing a client does is to send the server a "meta-command" to set up its search panel : it gets the number of criteria, their labels, the possible criteria values, etc. Client job is just an astract presentation one. When a user clicks the "Find" button, client job is still abstract : calling a method server-side with the combo-boxes current values passed as parameters. Client-side that operation has no meaning. Server-side, each value passed is identified as a search criteria and the job can be done. Now, as I support callbacks, I set as a property the fields on which a user may perform a search (I did it just to demonstrate that my callback support works, but in our discussion it can be used to demonstrate to you (or try to ) that in a 3-tiers design changes may require less work client-side, thanks to the higher level of abstraction of the client job). Well, when you change that property on the server and click the "Save" button, all clients adapt their interface accordingly, with ... no disruption.
Best,
Phil.

[Andrew Monkhouse]

Hi Phil,

Sorry Andrew, but I cannot follow you there. The more a client will be thin (a web browser is the thinest possible), the less it will need changes if new functionalities come up.

True, but we are not talking about a web client. At present we are talking about a client that must do some work, and must change whenever new business requirements are presented. My comment is that the fat client can handle most new business requirements internally. The thin client that you are using (not a web client) will need to have changes in both the client software and the server software.

This is probably one of the best parts of the instructions for the 3-tiers advocates : if we decouple the client job from the low-level database job, it's possible to change the db system (to a commercial one like Oracle - quite probable when they'll move to the web) "with minimal disruption to the users when this occurs."

I can see that in the case where there is a major change server side (such as changing the back end database), you may be able to hide that change from the client in the fat server solution.
However there is nothing to say that the same cannot happen with the thin client solution - all that changes is that the current functionality provided by the server becomes a fa�ade to the back end database. Changing the database should not necessitate any changes to the client software in either solution.
And just about any other change is better in a fat client solution. Compare what needs to happen if you have not implemented unbook(), and it becomes a requirement:

Fat client

add functionality to client software

do limited deployment to users

do full deployment when business accepts new functionality

zero downtime on server

Thin client

add functionality to client software

add functionality to server software

downtime on server while new server is deployed

depending on what changed on the server you may have to do full deployment of new client to all users, before business has accepted new functionality

Regards, Andrew

[Philippe Maquet]

Hi Andrew,
Your demonstration based on unbook() convinced me ... as far as 100% new functionalities are concerned. But for changes to existing functionalities, a fat-server / thin-client design should reduce global downtime (rare downtimes client-side and zero downtime server-side (if you set up some automatic server-switching feature as I described above)).
So, no winner no looser once more in this thread ?!
Best,
Phil.

[Amardeep Cheema]

Hi Andrew, Phil and Jim,

Alteratively, you could be asking whether we should be exposing the lock() method (and others) via the RMI or sockets connection. In which case we have discussed this a lot in the thread: "Should lock methods be callable by the client". I don't think anyone has discussed that from a security perspective yet

I have a couple of ideas why I think the client should NOT be allowed explicit access to record level lock and unlock methods on the server.
The starting point is the assumption that the client wants to do an atomic unit-of-work involving several records. The client should lock all the records before beginning any of the updates, and should release all the locks at the end.
Toy example scenario: I have the Early Bird hotel booking assignment, where each room record has a "number of beds" attribute. I can imagine a new business method "moveBeds" which moves a given number of beds from one room to the other, then I have to do Room 1 (-), Room 2(+) in one indivisible operation.
Now, if the client can lock individual rooms:
1. You increase the probability of deadlocks (for example, locking order differences leading to deadly embrace).
2. The client can mount a denial of service attack on the server by simply grabbing record locks and not letting them go.
I think that a design which allows the client to do implicit record locking is preferable. Note, I still don't think we should have a business method on the server which is doing the locking (I am still a 2-tierer). I guess a database function like the standard "commit" keeps all the record-level locking hidden from the client, and allows the server to make its own decisions. So in an ideal world I would have a different db interface which allows updates to be done within a hidden locking framework - perfect candidate to be a Template pattern kind of thingy.
As to what I plan to submit for the project, that is a different story. I have interpreted the instructions as strongly indicating a 2-tier design and that we should make all the methods on the data interface available to the client. So I will allow the client to lock and unlock.
By the way, just as an aside, I also think that unlock should not be bundled inside the server delete method. I think it is poor design to require explict lock and (sometimes explicit/sometimes automatic unlock). But I think it is ok to bundle the call to unlock() within the business delete method. I think this is what Andrew said in his latest comment, but it was not so clear on some of the other posts.
I was also wondering if the lock cookie value MUST be unique for each lock() call? There could be a higher level of grouping at the transaction level, where all the record locks within one transaction return the same cookie value.
In my (current) design I have a shared DBRepository object which uses instances of FileChannel, MetaData, LockManager, etc. I can easily see it using a TransactionManager which in turn delegates to a LockManager.
But this is by the by. Not relevant for the project to be submitted.
The trouble with Andrew's throwaway comments is that they get you thinking. And then you can't stop. Even when you're busy waiting for the bus, or chewing gum, or anything...
Deep

[Philippe Maquet]

Hi Deep,
Reading this :

I have a couple of ideas why I think the client should NOT be allowed explicit access to record level lock and unlock methods on the server.

I thought "Good boy !".
And reading the next paragraphs, I thought "Yes !" a few times.
... till this one :

As to what I plan to submit for the project, that is a different story. I have interpreted the instructions as strongly indicating a 2-tier design and that we should make all the methods on the data interface available to the client. So I will allow the client to lock and unlock.

Where are you reading in the instructions that they "strongly indicate a 2-tiers design" ?
I strongly believe that the new instructions strongly invite us to make a design choice of our own in that area.
As Nick noticed above (but with a wrong conclusion IMO), the old versions of the exam explicitely required a 2-tiers design :

Old instructions:
Writing Data Client:
To connect with your server, you should create a client program. This implementation should include a class that implements the same public methods as the suncertify.db.Data class, although it will need different constructors to allow it to support the network configuration.

The only relevant information here, is that they changed the instructions. And the fact that SUN, after having explicitely required a 2-tiers design, doesn't anymore is a clear indication that a 3-tiers one should be acceptable.
Anyway Deep, I noticed how much you progressed in the good direction this last week ... So next week, you should be perfect !
Best,
Phil.
PS: Andrew. Yes ! you definitely should invite Joe to join us here
[ October 13, 2003: Message edited by: Philippe Maquet ]

[Andrew Monkhouse]

Hi Deep,

I can imagine a new business method "moveBeds" which moves a given number of beds from one room to the other, then I have to do Room 1 (-), Room 2(+) in one indivisible operation.

This is a good example of something that can automatically be added to a fat client (2 tier) without any change or outage on the server. But if you go thin client (3 tier) then to add this functionality you are going to have to change the server (with a subsequent outage).
However you may not have deadlock handling strategies in place at the moment - in which case you should add them to the server if you wanted to handle this business functionality. But that is a side issue.
Following that side issue for a moment:
Jim made a good case for having deadlock avoidance by forcing locks to be granted to records in numerical order (so you cannot lock records 5, 3, 6 - you would have to lock them in order 3, 5, 6). Such processing adds almost no complexity to your code, and is good for future additions.

Now, if the client can lock individual rooms:
1. You increase the probability of deadlocks (for example, locking order differences leading to deadly embrace).

All your thin client / 3 tier solution does is move the location where locking is taking place. It has not removed the potential for deadlock.

2. The client can mount a denial of service attack on the server by simply grabbing record locks and not letting them go.

The client can mount a denial of service attack right now by booking every record in the database. Or if they can run a Java application on the same machine that runs your server app, then they could register another service in the registry with the same name as you are using - it will automatically displace your service.

I think that a design which allows the client to do implicit record locking is preferable. Note, I still don't think we should have a business method on the server which is doing the locking (I am still a 2-tierer). I guess a database function like the standard "commit" keeps all the record-level locking hidden from the client, and allows the server to make its own decisions. So in an ideal world I would have a different db interface which allows updates to be done within a hidden locking framework - perfect candidate to be a Template pattern kind of thingy.

Pity we can't do that though

As to what I plan to submit for the project, that is a different story. I have interpreted the instructions as strongly indicating a 2-tier design and that we should make all the methods on the data interface available to the client. So I will allow the client to lock and unlock.

To Phil:

I was also wondering if the lock cookie value MUST be unique for each lock() call? There could be a higher level of grouping at the transaction level, where all the record locks within one transaction return the same cookie value.

Yes, but at present there is no transaction support. If a client locked a second record, do you think that it is part of the same transaction or should the first transaction be suspended?
Possibly what you would need in that case would be some way of indicating to the lock() method whether the second lock is in the same transaction or not. This could be by passing the lock cookie in to the lock method, or by passing a boolean.
But I think this is getting out of scope.

The trouble with Andrew's throwaway comments is that they get you thinking. And then you can't stop. Even when you're busy waiting for the bus, or chewing gum, or anything...

Regards, Andrew

[Philippe Maquet]

Hi Andrew,

However you may not have deadlock handling strategies in place at the moment - in which case you should add them to the server if you wanted to handle this business functionality. But that is a side issue.

Side issue ?! Not for all of us !

Following that side issue for a moment:
Jim made a good case for having deadlock avoidance by forcing locks to be granted to records in numerical order (so you cannot lock records 5, 3, 6 - you would have to lock them in order 3, 5, 6). Such processing adds almost no complexity to your code, and is good for future additions.

Such processing adds almost no complexity to code bases which handle only one table. But for those of us (OK, it could be a majestative "us" ) who designed a multi-table database system, it's not a workable solution.

quote:
--------------------------------------------------------------------------------
Now, if the client can lock individual rooms:
1. You increase the probability of deadlocks (for example, locking order differences leading to deadly embrace).

--------------------------------------------------------------------------------
All your thin client / 3 tier solution does is move the location where locking is taking place. It has not removed the potential for deadlock.

It's not just a move : if locking is handled server-side, it will fully benefit of a try .. finally construct in case of client crash.

quote:
--------------------------------------------------------------------------------
As to what I plan to submit for the project, that is a different story. I have interpreted the instructions as strongly indicating a 2-tier design and that we should make all the methods on the data interface available to the client. So I will allow the client to lock and unlock.
--------------------------------------------------------------------------------

To Phil:

Mmh... A bit early to boast your success IMO : let Deep digest our posts and reply ... While he's justifying his 2-tiers design with 3-tiers arguments, I have a chance to win.

The trouble with Andrew's throwaway comments is that they get you thinking. And then you can't stop.

Same with threads. Andrew never gives up !
Anyway, it's time to publish new ratings. Taking into account that Andrew (2-tiers), as a bartender, has two votes, that Jim (2-tiers), as a Sheriff, has three votes, and that there are 1.5 more tiers in the 3-tiers system than in the 2-tiers one, the new ratings are :

2-tiers : 47.245 %

3-tiers : 52.755 %

Phew !
Best,
Phil.
[ October 13, 2003: Message edited by: Philippe Maquet ]

[Vlad Rabkin]

Hi Phil, Andrew and others,
I am done with my assignement. I am working on comments and documents right now. I plan to take the test in next two weeks (I have 2 tier design). If I still loose the scores for the locking, I will defently recognize your position that Sun doesn't concern aboaccepts and doesn't penalty 3 tier design.
Let's see...
By the way, sorry guys that I am not active last week in the forum. I just want finally get my assignement done and I will come back to you.
Best,
Vlad

[Andrew Monkhouse]

Hi Phil

Andrew However you may not have deadlock handling strategies in place at the moment - in which case you should add them to the server if you wanted to handle this business functionality. But that is a side issue.
Phil Side issue ?! Not for all of us !

Hmmmm. What I meant was that the added functionality Deep mentioned could be added to the two tier/fat client without any changes on the server. Now someone who has not coded any deadlock prevention/detection/handling onto their server might disagree because the server would need that extra code. But that does not negate my claim - adding the deadlock prevention/detection/handling is a side issue to the adding of functionality.

Andrew Jim made a good case for having deadlock avoidance by forcing locks to be granted to records in numerical order (so you cannot lock records 5, 3, 6 - you would have to lock them in order 3, 5, 6). Such processing adds almost no complexity to your code, and is good for future additions.
Phil Such processing adds almost no complexity to code bases which handle only one table. But for those of us (OK, it could be a majestative "us" ) who designed a multi-table database system, it's not a workable solution.

I am not sure that Jim's solution is unworkable in a multi table database.
Regardless, I do like your recursive deadlock detection better anyway - it saves the whole issue of trying to force clients to lock records in order.
But then again - your recursive deadlock detection system seems perfect for the two tier solution

Deep Now, if the client can lock individual rooms:
1. You increase the probability of deadlocks (for example, locking order differences leading to deadly embrace).
Andrew All your thin client / 3 tier solution does is move the location where locking is taking place. It has not removed the potential for deadlock.
Phil It's not just a move: if locking is handled server-side, it will fully benefit of a try .. finally construct in case of client crash.

We were talking about deadlock, not client crashes.
Client crashes may require more than just a finally clause for clean up. So this benefit (IMHO) is not so great.

Phil Anyway, it's time to publish new ratings. Taking into account that Andrew (2-tiers), as a bartender, has two votes, that Jim (2-tiers), as a Sheriff, has three votes, and that there are 1.5 more tiers in the 3-tiers system than in the 2-tiers one, the new ratings are :

2-tiers : 47.245 %

3-tiers : 52.755 %

Hmmm - I think you did some creative mathematics there Phil.
By my count:
Two tier

Andrew

Jim

Tony (changed vote )

Vlad

Arun

Bharat (changed vote )

Chris (not sure if 2 or 3 tier)

Deep

Three tier

Phil

Michael

Suds

Ken

Peter

Don't know

Dushy

Regards, Andrew
[ October 13, 2003: Message edited by: Andrew Monkhouse ]

[Andrew Monkhouse]

Hi Vlad,
Excellent news. Good luck (not that you need it), and see you back here soon.
Regards, Andrew

[Philippe Maquet]

Hi Andrew, Bharat, Dushy and Tony,

Andrew:
Hmmm - I think you did some creative mathematics there Phil.

Yes, they were creative on purpose because I was not energetic enough to make a new count. Thank you to have done it.
But I found you were quite creative with Chris ranking : about him you write "(not sure if 2 or 3 tiers") ... but you rank him as a 2-tiers advocate !
So I checked Chris's last posts and it's clear that after some hesitation, Chris is definitely in the right team.
And I checked too the two "changed vote" (and nothing else BTW), and found you were quite creative in your interpretation of Tony's and Bharat's opinion ! They should be ranked with Dushy under "Don't know".

Dushy:
But after Tony's result, im skeptic about taking the three tier approach.

Tony:
Well I lost alot of marks on my locking strategy, so maybe the 2 tier gang are right.

Bharat:
Hello Dushyant,
You wrote:
quote:
--------------------------------------------------------------------------------
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 regret that Tony got his results in the few days where I was not active on this forum, because I am sure that he lost no point in the locking area because of his 3-tiers design. If not too late for the "don't know" guys, here is my argument about it :
The title of this thread "Should lock methods be callable by the client" is misleading (sorry Andrew). In the old instructions, it was stated "To connect with your server, you should create a client program. This implementation should include a class that implements the same public methods as the suncertify.db.Data class", clearly requiring a 2-tiers design. The 2-tiers design is "exposing the db interface to the client" and not "exposing the lock/unlock methods to the client". Now with the new assignments, in the improbable case the grader would make you loose points because of a 3-tiers design, there is no logical reason to deduct points in the locking area, or anyway not in the locking area alone.
Anyway, and while Bharat, Dushy and Tony don't write that I just convinced them , here are the corrected scores :
2-tiers = 35.7%

Andrew

Arun

Deep

Jim

Vlad

3-tiers = 42.9%

Chris

Ken

Michael

Peter

Phil

Suds

Don't know = 21.4%

Bharat

Dushy

Tony

Andrew:
We were talking about deadlock, not client crashes.

Client crashes are one of the two possible causes of deadlock. And for the many people who don't allow more than one lock at a time (not me, but well all those among others who use Max's WeakHashMap solution), clients crashes are even the only possible cause of deadlock.

Andrew:
Client crashes may require more than just a finally clause for clean up. So this benefit (IMHO) is not so great.

Maybe for clean up, but not just to avoid the deadlock situation we are talking about.
Best,
Phil.
PS: Bharat, Dushy and Tony : I count on you.
[ October 14, 2003: Message edited by: Philippe Maquet ]

[Philippe Maquet]

Hi Vlad,

Hi Phil, Andrew and others,
I am done with my assignement. I am working on comments and documents right now. I plan to take the test in next two weeks (I have 2 tier design). If I still loose the scores for the locking, I will defently recognize your position that Sun doesn't concern aboaccepts and doesn't penalty 3 tier design.
Let's see...
By the way, sorry guys that I am not active last week in the forum. I just want finally get my assignement done and I will come back to you.
Best,
Vlad

Great news ! It's so nice to see the finishing line coming !
If I speed up a bit, I should finish in two or three weeks. It's probably a good idea to be less active on this forum in the meantime. I'll think of it too, coming back in strengh after uploading.
As Andrew, I know that you don't need it, but anyway I say "Good luck" !
Cheers,
Phil.

[Andrew Monkhouse]

Hi Phil,

But I found you were quite creative with [Chris & Bharat & Tony's votes]

I guess I should have closed the thread while it appeared I was winning

I am sure that [Tony] lost no point in the locking area because of his 3-tiers design. ... Now with the new assignments, in the improbable case the grader would make you loose points because of a 3-tiers design, there is no logical reason to deduct points in the locking area, or anyway not in the locking area alone.

I should have noticed that. You are correct - if there was a problem with 3 tier, then logically Tony should have lost some points in the "Network Server" category - but he got 100% for that. So it is more likely that there was actually a problem with his locking code.
Regards, Andrew

[Philippe Maquet]

Mmmh !

I guess I should have closed the thread while it appeared I was winning

Yes, and - unfortunately - I cannot do it myself.
Best,
Phil.
[ October 14, 2003: Message edited by: Philippe Maquet ]

[Amardeep Cheema]

Hi Andrew and Phil,
thanks for taking the time to consider my post and reply.
As Andrew rightly pointed out, my issues did not really have anything to do with the 3-tier/2-tier discussion. A better title would have been "should lock/unlock methods be in the database interface at all".
Anyway, I have decided that it is a very good idea to implement some kind of deadlock avoidance/detection/handling in the server. But I need to do more research on this area.
Phil, after your post, I read this thread and the instructions yet again but unfortunately, I am tending even more to the 2-tier camp. Sorry!
Vlad - good luck.
best wishes, Deep

[Philippe Maquet]

Hi Deep,

Anyway, I have decided that it is a very good idea to implement some kind of deadlock avoidance/detection/handling in the server. But I need to do more research on this area.

I think it's a good idea. My argument about it (often written, but I repeat it here) is that :

Deadlock is the worst scenario any application may encounter

From the customer's perspective, there is no difference between a program hanging because of a synchronize-deadlock and a program hanging because of a database-deadlock : if it hangs, it just hangs, period.

If I wrote above that Jim's solution is not a solution, it's because it's a "human" one. The programmer must follow a "good practice" of claiming locks in ascending record numbers order. As the system cannot enforce that rule (or with much more code that I wrote to detect real deadlock situations), it's not a "software" solution. Worst, within a multi-table system which allows multiple locks to be granted on multiple tables (as I designed it), such a "human" rule would quickly lead to a programmer's nightmare : if record numbers order is easy to understand and remember, what about the arbitrary tables order he needs to follow too ? Asking the question brings the answer ...

Phil, after your post, I read this thread and the instructions yet again but unfortunately, I am tending even more to the 2-tier camp. Sorry!

I don't care, Deep, you were already counted in the 2-tiers camp.
Anyway, after you'll vote for the 3-tiers design, we'll discuss further about deadlock detection is you want.
Best,
Phil.
[ October 14, 2003: Message edited by: Philippe Maquet ]

[Janus Smythe]

Hello all -- I've just begun the SCJD, and this is my first post. My assignment is the Bodgitt / Scarper one.
I found Sakke Wiik's post from last week very interesting, because I have likewise been assuming that the locking strategy suggested in the DBMain interface is a high level kind of lock, not a low level one. In other words:

A CSR selects a contractor to book and hits, say, a 'book' button. At this point, the GUI executes isLocked() on the database. If true, inform the CSR that another CSR is editing this entry.

If not locked, test to see if the record is still unbooked. If not, inform the CSR.

If the record is not locked and not booked, lock it, and wait for the CSR to type in the client's ID and submit -- which he may now do at his leisure, knowing nobody else will be able to snag the contractor while the CSR is talking to the client.

Whether the CSR books or cancels (timeouts are not handled well in this scenario) -- the record is finally unlocked for other CSR's to eye.

The primary reason for this assumption is that, as this thread has already discussed at great length, it's crazy to export something as vital as record locking over something as inherently fragile as a network connection.
The second reason -- and please correct me if I'm wrong -- is that as far as I can tell, DBMain's locking mechanism simply sucks for low-level locking -- the comments specifically state that locking is only meant to prevent writing by different clients. But what about a thread that's mid-read when another thread comes along and rewrites the record?
This makes no sense to me. I would synchronize -any- operation, read or write, for a given record. If you want to be a bit fancier, allow concurrent reads but no writing while reading and no reading while writing.
Andrew's response to Sakke's post:

Originally posted by Andrew Monkhouse:

Your concept is interesting. However do you have a requirement for the lock() method to block until the lock is granted? Usually there is some statement similar to "If the specified record is already locked by a different client, the current thread gives up the CPU and consumes no CPU cycles until the record is unlocked". If you do have such a statement, then client 2 will not get notification that the record is currently locked.
That being the case, if client 1 locks the record and then goes out to lunch, client 2 will be blocked until client 1 comes back.
The problem is that locking isn't just for setting the client ID. You might want to lock a record to delete it. Or (although it is not currently required) you might want to lock a record so you can remove an invalid client booking. So the lock method cannot really care about whether the record has already been booked or not. Plus, depending on your lock signature, you might not be able to indicate that the record has been updated.

Well, The requirement that lock() blocks until the lock is granted is an emergency specification only: my interface contains a boolean isLocked(), which is what the GUI ought to be using.
The time-out problem, however, is admittedly severe. I still prefer this interpretation -- I'd rather have flaky high level locking in the GUI than server-side data corruption!

I suspect I'm missing something obvious, and would love to have it pointed out to me.
Janus

[Andrew Monkhouse]

Hi Janus,
Welcome to JavaRanch (and this never ending thread).
Your scenario requires you to do several steps twice. In your scenario:

(with my numbering)

A CSR selects a contractor to book and hits, say, a 'book' button. At this point, the GUI executes isLocked() on the database. If true, inform the CSR that another CSR is editing this entry.

If not locked, test to see if the record is still unbooked. If not, inform the CSR.

If the record is not locked and not booked, lock it, and wait for the CSR to type in the client's ID and submit -- which he may now do at his leisure, knowing nobody else will be able to snag the contractor while the CSR is talking to the client.

Whether the CSR books or cancels (timeouts are not handled well in this scenario) -- the record is finally unlocked for other CSR's to eye.

Another client can lock the record immediately after step 1 completes.
Another client can book the record immediately after step 2 completes.
So step 3 should be done before step 2, otherwise you would have to perform step 2 twice.
In step 3 you have locked the record before the CSR has entered the customer's number. So you would have to call the lock method from the client software to do this. But this contradicts your desire to not expose locking to the network.

the comments specifically state that locking is only meant to prevent writing by different clients. But what about a thread that's mid-read when another thread comes along and rewrites the record?

But the locking is only a logical lock that your server will use to indicate that nobody else can update the record that you want to update. It is not a physical lock on the record on disk preventing any unfriendly process from writing to the disk.
This is separate from writing thread safe code which will hopefully prevent you from reading a record while it is in the process of being written to.

Well, The requirement that lock() blocks until the lock is granted is an emergency specification only: my interface contains a boolean isLocked(), which is what the GUI ought to be using.

The isLocked() method is advisory at best. As mentioned before, any other client can lock the record after your client has called isLocked() and before your client calls the lock() method.
The isLocked() method works well in the scenario you are describing where you want to lock the record and then some time later modify it.
However many candidates (even those with Bodgitt & Scarper assignments) do not have the isLocked() method in their interface. These candidates get by without it.

I'd rather have flaky high level locking in the GUI than server-side data corruption!

Data corruption is a big no-no.
But I have not seen anything that anyone has posted that would lead to data corruption (apart from those who forget to do the check the record status after locking the record - and that applies no matter whether the locking is performed by client or server). So whaat do you think is going to cause the corruption?
Regards, Andrew

[Davidd Smith]

Hi, all,
What a crowded thread!
I use 3-tier mode and call lock method on the server. I passed, but I loss 36 point about Locking and 6 point about General Considerations , I do not know whether it due to 3-tier.
Thanks all of you, especially Andrew. Without your help, I would not have even completed my assignment, so I hope my score could have some value for reference. I'll fell sorry if it is against Andrew.
Regards
Davidd