• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Ron McLeod
  • Carey Brown
Bartenders:
  • Paweł Baczyński
  • Piet Souris
  • Vijitha Kumara

Discussion on Designing reservation system

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,

Could you please let me know how can we design (any) reservation system? Could be movie tickets, bus tickets etc.

Basically I would like to understand which collections to be used, for ex when two users trying to book the same ticket at a time how can we avoid.

I am thinking of using HashMap with synchronization concepts or is there any other standard collection or design that can be used here.

Please provide your thoughts on this.

Thanks.
 
Saloon Keeper
Posts: 6419
60
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think you're jumping in too quickly into the 'how'. I would suggest first looking at the nouns and verbs in your requirements and come up with some sketches of classes (nouns), their fields (member variables), and methods (verbs). Also outline the relation ships between them, e.g. 'is-a' or 'has-a'.
 
Surya Surrya
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Carey for your prompt reply. I did go through all those. Now, I am actually looking into the specifics to the collections that can be used here. It would be really great if you can share your thoughts on the collections that can be used in this.
 
Carey Brown
Saloon Keeper
Posts: 6419
60
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, you haven't posted the classes or the requirements so it's impossible to say at this point.
 
Bartender
Posts: 10777
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Surya Surrya wrote:Please provide your thoughts on this.


I agree with Carey. You first need to deal with what you want to happen - and I doubt that there is a single approach that will work for any type of reservation.

Take a seat on an train, aircraft, or in a theatre. There you'll certainly need a collection that can identify the individual seat and distinguish it from others, so a Map of some kind sounds reasonable. But what about a shopping cart that deals with an item of stock? There you'll be checking whether your "reservation" (ie, your order) can be fulfilled based on availability, which is kind of different.

Also: simple locking isn't going to solve your problem: Do you really want to have someone wait to find out whether they can book a seat or not? I suspect not.
What's more likely is that you'll want your seat (if that's what you're dealing with) to have some sort of status attribute, eg:
Available
Locked (ie, "being processed")
Reserved
Now you may well need synchronization to update it, but you certainly shouldn't need to lock other users out from reading it, so I don't think synchronizing the collection is the answer. Indeed, once you've loaded your "seats", I doubt whether your collection will need to change at all.

My suggestion: Try to come up with scenarios that you're concerned about. Things like:
A and B decide to book the same seat at the same time. Who gets first dibs? How do you inform the other user that they missed out?
What do you want to do if a reservation is aborted?

HIH

Winston
 
Surya Surrya
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Winston.

Thanks for your reply.

Consider the below usecase,

1) User A and User B trying to book a movie ticket.
2) Both logged into the system at same time say at 10:00 AM
3) Only one ticket is available for that movie.

Here my queries are

1) Who will get the ticket user A or User B? reason for this?
2) Do we need to load all the available seats into cache when user logs in?
3) What collections can be used in this cases?
4) Do we need to use synchronization?


Thanks,
 
Sheriff
Posts: 24654
58
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Surya Surrya wrote:1) Who will get the ticket user A or User B? reason for this?



One of them. Presumably the first one whose request is processed, but there are other possibilities. Perhaps the more important one (Platinum Level versus Gold Level) should get it? There are no rules which constrain your design.

2) Do we need to load all the available seats into cache when user logs in?



This is the first time you've mentioned that your design involves a cache. Why is there a cache and what's the backing store which you are caching?

3) What collections can be used in this cases?



We still haven't seen any design or classes, so we still can't make any suggestions.

4) Do we need to use synchronization?



Yes, something is going to have to prevent two reservations from being processed in parallel and depleting the inventory to below-zero levels. However it doesn't follow that your code would have to use synchronization -- for example you might be putting those requests on a queue to be handled, and then somebody else's code might be using synchronization to make sure the two messages don't mess each other up.

I'm sure that people have already said this, but you shouldn't be asking those questions before you have a design that you can ask questions about.
 
Winston Gutkowski
Bartender
Posts: 10777
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Surya Surrya wrote:Here my queries are
1) Who will get the ticket user A or User B? reason for this?


Personally, I'd start out with "first click gets" - ie, first come, first served - because it's generally the easiest to implement. You can worry about "gold card" stuff later once you've got the basic system working.

2) Do we need to load all the available seats into cache when user logs in?


Depends very much on what you want. If you load all the seats for the cinema in question, then you could create a visual "seat plan" so people can decide where they'd like to sit.

3) What collections can be used in this cases?


Well, any time you need to reference an individual Item via a key (eg, for a seat: row + seat number), then a Map is generally what you want.

4) Do we need to use synchronization?


Yes, but you want to make it as minimal and short-lived as possible. Anything that involves a human being is going to bepainfully slow for a computer so, for example, if it takes an average of 5 minutes to book a seat, you don't want to be locking out other users while that's happening. And since a booking only involves one seat (or maybe a few), you only want to be locking the seats involved in the booking, not the whole app.
Which suggests strongly to me that each seat should be an object, defined by a Seat class.

Secondly: Even if someone is in the process of booking a Seat, you don't want to be locking other users out from viewing it while it's going on, which is why I suggested a status code. In a setup like that, the very first thing that happens is to update the Seat's status from 'available' to 'locked' so that other users can see immediately that the Seat is unavailable. And if that update is synchronized, then only ONE user will actually get to do it.

Another possibility is to have each Seat contain a "lockedBy" field. If it's null, the Seat is available; otherwise it contains the reference of the User who successfully locked it. The advantage of that technique is that then unsuccessful Users know straight away that "it wasn't locked by me". The only thing you usually have to be careful of in any synchronized scenario like is that you check the status after locking and before updating, viz:
There are many ways to do it, the above being just one; but whatever method you do choose, the main thing to remember is that synchronisation should be as short-lived as possible: ie, lock→update→unlock.

HIH

Winston
 
You're not going crazy. You're going sane in a crazy word. Find comfort in this tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!