Lock implementation

[Roberto Demestri]

I ran the Perillo script for testing the locking code and it works fine.
My question is how to implement this on the GUI interface; so actually
1) When I perform a search all record available are considered (locked and unlocked)
2) When the user choose one, then a Popup is shown... and when the user hits "Save" when update/delete is performed data the bussinees layee checks if the record
is locked for the current client and perform the operation.
Should the record got to be locked when the popup is shown regardless of what the user is doing? and then released??
Actually if two clients edit record number 5 and modified it; both can do it and the last one result persisted on DB

[Roberto Perillo]

Howdy, Demestri!

1. Actually, all records that match the search criteria should be retrieved, no matter if they are locked or not.
2. I'm not sure if I got your point... but, I think what you are saying is, when the user chooses a record on the JTable and presses the "Book" button, then a popup is shown, right? So, after that, the bookRoom method of your business layer should be invoked... and there, a lock()/update()/unlock() sequence will happen. You first have to lock the record, then verify if it is still available (via read() method), and if so, then the update() method should be called, updating only the customer field of that particular record. After that, you call unlock(), and inside the unlock method, you should notify all waiting Threads.

In order to show the popup, the record doesn't have to be deleted. You can just populate its fields with the corresponding fields of the chosen record, and when the user hits the "Book" button, then the lock()/update()/unlock() sequence is called inside your bookRoom() method in your business layer.

And remember that, the delete() method of the Data class must be implemented, but it isn't used anywhere in the implementation.

[Roberto Perillo]

And by the way, if two clients hit the "Book" button at the same time, only one of them should succeed. And that's exactly where the locking mechanism fits in. One of them will get a success message, and the other one should get a "room already booked" message.

[Jim Hoglund]

Is it not true that the project asks for a booking system? It seems that this would
include a verified delete function. And the locking mechanism should lock only the
record of interest, not the entire database. So the timing of the concurrent update
test must be automated to assure that a collision will actually occur. In general, I
am wondering how to handle general (common sense) requirements that lack detail
in the assignment. Any comments?

Jim ...

[Roberto Perillo]

Well, it is true that the project asks for a booking system. And, in real life, it certainly would include a delete function. But, one doesn't have to be implemented for this project.

For requrements that lack details, the developer must be capable of filtering what must be done and what doesn't have to be done. Many of these requirements can be found here in the forum, and have been discussed quite a lot now... but, in general, the developer must make decisions with the available options and justify them in the choices.txt file.

[Jim Hoglund]

Yep, and that means that I will build a relatively full-reatured booking system. I know
that extra credit is not offered, especially against missing a stated requirement. But I've
worked for many years in software development and a big frustration has been in dealing
with software engineers and programmers when they want to ignore obvious needs, blaming
it on an incomplete or ambiguous requirement spec. Of course, experienced developers don't
do this; the very best insist that the requirements be revised and that everyone shares a
common understanding of what is called for.

Jim ...

[Roel De Nijs]

My view on things:
1/ when you search records, all matching records should be returned (makes no difference if they are locked or not)
2/ you should always try to keep the actual locking time as short as possible, so when the user confirms the popup, the record is locked, updated and unlocked. When 2 clients book the same room, 1 client will actually book the room. The other client will get a "this room is already booked" exception, because (of course) you do not want double bookings of a room

[Roel De Nijs]

Jim Hoglund wrote:But I've worked for many years in software development and a big frustration has been in dealing with software engineers and programmers when they want to ignore obvious needs, blaming it on an incomplete or ambiguous requirement spec.

I don't think this spec is incomplete. They (business people) just want the most important functionalities (searching and booking) in the shortest possible time (deadline), because now CSRs lose a lot of time with the outdated system. So I delivered what they asked: nothing more, nothing less and I met the deadline, the CSRs can now book 5x more people than with the previous system (and because they work on commission, they were very thankful )

[Roberto Demestri]

Thanks for the quick answers.
I implemented everything (Add, Update and Delete). For Add and Delete I got no problems.
The Update function was re-implemented in the following way:
N clientes can try to book the same room; so N popups will open.. and no lock is performed at that time
The first to press "Save" win the prize... all the others will get a "Already booked" message when they hit save
The lock is reduced to a minimum; just when the change is to be done... and an extra check was added at the saving time
(basically check is the db row has already an owner)
And everything holds... but now... when a room is booked, it only can be deleted (can't update anymore, already has an owner) ... is this the expected behavior ?
or this limitation will go to choices.txt?
Regards.

[Roel De Nijs]

There is no delete functionality from the gui, because that's not a must requirement (only find and book). So very few people have a delete-button in their gui.

[Roberto Demestri]

i know... i just implemented them all...

[Roel De Nijs]

If you implemented them all, why not having an unbook-button? (just being the devil's advocate)

[Greg Funston]

The URLyBird assignment also emulates an iterative design approach. Sometimes when the customer asks for a project specification such as this they want to see what they will get and then make future decisions based on those results. The specification calls for using the old data file system and hints that a future system design may not use this database file. Also the delete function is used to book rooms. Despite the fact that the delete button does not need to work the delete function does. The assignment as it is stated also leaves room for some debate over what is to be delivered but specifies specifically what must to be delivered. If more than is requested is delivered it may specifically not be wanted and even has potential for harm.

For example: Lets say the delete function is active and it is accidentally hit. The record could no longer exist and there is no safeguard for accidental hits. Also if you add a create or modify it may not meet the needs of the URLyBird system. Without this specification you as a designer may be wasting you or your employer's time and money and you may do things which the client specifically does not want. Personally I did not have a Delete function in my GUI even though the button was present. I documented all my decisions including this one and mentioned iterative design as the approach being used here as that seemed obvious to me.

Cheers,
Greg Funston OCPJP, OCMJD

[Sean Keane]

Greg Funston wrote:Personally I did not have a Delete function in my GUI even though the button was present. I documented all my decisions including this one and mentioned iterative design as the approach being used here as that seemed obvious to me.

Hi Greg. What was the thought behind placing a delete button on your GUI that did not work?

This is the first time I've heard a mention of placing a delete button on the GUI that does not work. From reading the forum, I got the impression that most other people just implement the delete functionality on the server side, but they do not make it available on the client side.

[Greg Funston]

Sean Keane wrote:
Hi Greg. What was the thought behind placing a delete button on your GUI that did not work?

This is the first time I've heard a mention of placing a delete button on the GUI that does not work. From reading the forum, I got the impression that most other people just implement the delete functionality on the server side, but they do not make it available on the client side.

I put the Create, Modify(update) and Delete Buttons in my GUI. They were all disabled. The idea was future use. I documented this choice. This is not a requirement but it is easy to implement and impacts the overall GUI look so it met the project's requirements. Since the GUI is re-usable as long as it is not replaced with a web page the GUI having future functionality and a consistent look makes sense. It is also very easy to implement unlike a custom table.

Cheers,
Greg Funston OCPJP, OCMJD

[Greg Funston]

One thing I would like to add to these posts. I treated this assignment as if it was a real life assignment. My thinking was trying to think:

What does my employer want?
What does the customer want?

I think in the real world meeting the specification and not exceeding it is important to both employer and customer. You can go beyond the specification slightly and exceed expectations but too much is a mistake. Both your employer or the customer may be unhappy. Remember you can ask neither for clarification. The documentation required in this assignment is important and a significant amount of work by itself. Creating excess functionality outside the design is needless and could be costly.

Cheers,
Greg Funston OCPJP, OCMJD

[Roberto Demestri]

Well... we're going on another direction
Just for finalize the topic; the hints given about implementig the lock are taking in consideration in my implementation.
For the curious, I implement on the GUI all the functions presented on the DB interface, basically because it help me through the tests.
But I also think that a spec for a Certification like this can be written better... a lot better...
Thanks people!

[Roel De Nijs]

Roberto Demestri wrote:For the curious, I implement on the GUI all the functions presented on the DB interface, basically because it help me through the tests.

That's why you have testing frameworks like JUnit and TestNG. I first finished my Data class completely, then my business service implementations and finally I developed my GUI. So I used JUnit to have full test coverage of my Data class and business service implementations. I didn't proceed with the next step until the previous one was completely finished.

Roberto Demestri wrote:But I also think that a spec for a Certification like this can be written better... a lot better...

I think it's really intentional that the spec you got is a bit vague. Because that's how it might be in your real job too (think about the famous dilbert cartoon). I think the spec is great for such an assignment: it makes you think, evaluate different approaches, makes you wonder if there is not a better alternative, defend the choices you made,... I really enjoyed doing this assignment (which might not be the case if the assignment would completely be written down, with no room for adding your own bits and pieces)