NX UyB: Booking fails, then what?

[mike acre]

When booking a room fails it is because the record data you hold at the client end does not match up with the record data at the server end during a call to book()

ie

lock > read > matches? yes > modify > unlock

if(matches == no) then you can throw an Exception.

are people differentiating between the two subsets of this condition

1/ room now booked
2/ other room data modified. (eg smoking to non-smoking)

Obviously it is a good idea to do this.

I have a business object that is queried, not a String[].
I have implemented equals & hashCode for the initial check, but I need a little more info. hey ho, more code...

Just wanted a discussion of this area of business logic.

[peter wooster]

Originally posted by mike acre:
When booking a room fails it is because the record data you hold at the client end does not match up with the record data at the server end during a call to book()

ie

lock > read > matches? yes > modify > unlock

if(matches == no) then you can throw an Exception.

are people differentiating between the two subsets of this condition

1/ room now booked
2/ other room data modified. (eg smoking to non-smoking)

Obviously it is a good idea to do this.

I have a business object that is queried, not a String[].
I have implemented equals & hashCode for the initial check, but I need a little more info. hey ho, more code...

Just wanted a discussion of this area of business logic.

I'm working on design of this area at present and my opinion is when the user picks a row out of the table to book, the client should send the current value to the server and request that the server do the booking. If the client's version of the record differs from the server's version a response that includes the server version should be returned to the client with an indication that the booking failed and the user should be given the option to retry or cancel the booking.

Whether the record is locked at this point is something I'm still debating. If you lock it, you must worry about a locked record when a client goes away. If you don't lock it all locking only lasts as long as one client transaction but there is a possibility that this sequence could repeat indefinitely.

[mike acre]

Howdy Peter!

I'm working on design of this area at present and my opinion is when the user picks a row out of the table to book, the client should send the current value to the server and request that the server do the booking. If the client's version of the record differs from the server's version a response that includes the server version should be returned to the client with an indication that the booking failed

I have RecordModifiedException & RecordBookedException that do just that.
I also thought about returning the new record version, RecordModifiedException could take that Record as an argument.

and the user should be given the option to retry or cancel the booking.

However, I think that is going too far. I'm already caught out a little by the extra work a thin client is taking. I shall just leave it to the user to book the record in the usual way from the table.

Whether the record is locked at this point is something I'm still debating. If you lock it, you must worry about a locked record when a client goes away. If you don't lock it all locking only lasts as long as one client transaction.

mmmm, forgive if I misunderstand:

When the booking fails due to modified record, not found, etc. Then the book method will be locked at that point.
I throw an Exception and I will unlock the record.
Are you proposing you keep it locked, with the idea that client may rebook?

I think that is a bad idea. The whole process should begin again as if it never failed.

However...

but there is a possibility that this sequence could repeat indefinitely

I don't see that this would happen. Perhaps you need to explain your last paragraph more carefully.

Have a look at my other recent thread, also in the same area of the design.

Cheers Peter!

[Anton Golovin]

I think that if it does not match, the only way it may fail to match is if the record was booked prior. There is no option in the program to change an extant record other than the booking customer ID.

[mike acre]

Originally posted by Anton Golovin:
I think that if it does not match, the only way it may fail to match is if the record was booked prior. There is no option in the program to change an extant record other than the booking customer ID.

True

The spec says 'the data must continue to be manipulated for reports using another custom written application'

So reporting is read only.

So I guess we can make this assumption.

[peter wooster]

Originally posted by Anton Golovin:
I think that if it does not match, the only way it may fail to match is if the record was booked prior. There is no option in the program to change an extant record other than the booking customer ID.

I agree that at present the only cause of a mismatch is that someone else booked the record. But my instructions say "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." I read that as meaning that the application will eventually be able to modify, add or delete records. All of these can cause the displayed records to become stale.

It's also possible that there is a legacy client that does allow these, it might even be used by the markers to confirm that we can recover from stale data in the display. I actually intend to write a maintenance client that can do these kind of things for testing, I don't think I'll build it into the submission, but my network layer will support all of those commands.

[peter wooster]

Originally posted by mike acre:
Howdy Peter!


I don't see that this would happen. Perhaps you need to explain your last paragraph more carefully.

Have a look at my other recent thread, also in the same area of the design.

Cheers Peter!

If another user was actively updating the record, not just booking it but changing the attributes of the room this sequence could repeat several times, probably not really indefinitely, just annoyingly. At present I agree with you that if we are doing a thin client, that all locking must only occur on the server and all client commands should be atomic.

[Jashua Ni]

To my understanding(for my assignment), there is 48 hour limitation. The room has to be booked within 48 hours. It looks that this is not a condition that will make the book fail besides customer id?

Does anybody any suggestions for this?

[mike acre]

Hi Jashua,

The 48 hour rule is probably best implemented by using SimpleDateFormat to parse the Date, then subtracting the current Date.getTime() from it.

Where you do it is more open to opinion. Personally, being in the thin client camp, I have a Record object that wraps the row data and applies this rule before exporting to client. However I'm far from convinced this is the best place for it so would like opinions. I'm sure I need it within some form of 'transfer object' since the client, even though it is thin, needs to do some business checking to maintain the advantages of being thin, ie not having to make a network call to determine if the record is bookable.
So a thin client must know what records are potentially bookable and so must have some business knowledge.

If you are a fat client this is likely unhelpful.

[peter wooster]

Originally posted by mike acre:
Hi Jashua,

The 48 hour rule is probably best implemented by using SimpleDateFormat to parse the Date, then subtracting the current Date.getTime() from it.

Where you do it is more open to opinion. Personally, being in the thin client camp, I have a Record object that wraps the row data and applies this rule before exporting to client. However I'm far from convinced this is the best place for it so would like opinions. I'm sure I need it within some form of 'transfer object' since the client, even though it is thin, needs to do some business checking to maintain the advantages of being thin, ie not having to make a network call to determine if the record is bookable.
So a thin client must know what records are potentially bookable and so must have some business knowledge.

If you are a fat client this is likely unhelpful.

I read the instructions somewhat differently. They say "they take bookings only within 48 hours of start of occupancy". For this reason the customer rep must be able to see all available rooms and the software should not prevent booking, but must check the time and warn the rep if the room is too far in the future. I've read somewhere here that there is an automatic failure for not doing something with this extremely vague requirement. It would be nice to get some advice from someone who has passed this assignment. You will note that the data file as provided makes it nearly impossible to fulfill this requirement, many of the dates are in the past and most of the rest are far in the future.

Also the there is not checkin time defined so I assume the 48 hours is 48 hours before 0000 on the day listed. Also no mention is made of timezones so I assume that all times are in a specific zone such as UTC or the time on the server. If the client, server and location are in different time zones this makes a difference.