Saturday, November 04, 2006

Multiple booking

The project that I am working with at the moment is a flight booking system that could allow the user to book many seats at once. That means that the user should be able to select the flight and the number of seats that he wants to book, book these seats, and then start filling the details of the passengers one after the other.

The obvious problem is that if you don't lock some tables somehow, it is possible that while the user fills in the details, another user could book his seats, and that could cause that there are no more seats available even though the user has entered his information and thinks that he booked..

The table that are used here are [ Passsenger, Flight, Booking ]
Where obliviously Passenger has the details of the passengers, Flight has the details of the flights and Booking has the PassengerID and FlightID to uniquely identify a booking.

The only "nice" solution that I found is the following.
When the user presses the button to book( s seats at f flight), I create s Passengers with only temp data(actually only firstname='temp'). Then I create s Bookings of these Passengers. Then the data layer returns a List that contains the newly created PassengerIDs and BookingID. This list will be used to fill in the data of the passengers and some more data about the booking(delivery address, meal choices etc)

Do you have any better solution?
Mine is working, but I don't like it a lot. I need to access the database many times and that costs when we are talking about a web application. However, I think that you have to access the database at least twice if you want to do something like that since you want to book in advance and fill in the data later.

I am working with aspx and c# with .Net Visual Studio 2005 and SQL Server 2005.

2 comments:

psarog said...

What if customer doesn't proceed with the data filling? Is there a mechanism to remove temp passengers?

Stavros said...

Thanks for pointing out. I didn't start considering what to do if something goes wrong..

However, my first thought is to keep a timestamp of creation of each Passenger, and run a service at the server that once a day will check if a Passenger is in the database for a day or more and delete this passenger. I know I can catch the event of browser closing, but I guess that timestamp is better solution since you do not depend on the client's software.