i am doing online cinema reservation project, and i have this problem in
the Reservation Process, i want the user to always experiance a Fresh
version of the Seats avaiable for him to book, the problem is divided
into 2 parts :

first how to make sure that the seats avaiable to him is the latest
uptodate of the database, as he opend the page and other users may had
made reservations and he is not allowed to reserve a seat that is
already reserved, and from the Interface prospective the user should
have a REAL data about the avaiable seats..

the secound part of the problem is what about the users booking the same
seat at the same time ? how can i handle this, i am sure that the
airlines companys already solved this problem while working on their
distribuated database system but how is it done ??


if anyone can help by suggestions, commments, or partial solutions. that
would be GREAT.

Thanks




Sharing makes All the Difference

--
Sent via .NET Newsgroups
http://www.dotnetnewsgroups.com

Hi,

Dave Johnson wrote:
> as he opend the page and other users may had
> made reservations and he is not allowed to reserve
> a seat that is already reserved, and from the
> Interface prospective the user should
> have a REAL data about the avaiable seats..

It sounds like you are building a web based interface, which makes that
rather difficult.

There are some techniques for enabling server-to-client communication for
web clients. Most involve refreshing another page in a hidden iframe, in
which the server-side code can insert Javascript to trigger client-side
events as needed -- such as refreshing the available seats map. However,
these are not fast enough to rely on them in your situation, without
providing an alternate code path.

> the secound part of the problem is what about the users
> booking the same seat at the same time ? how can i handle
> this, i am sure that the airlines companys already solved this
> problem while working on their distribuated database system
> but how is it done ??

Most reservation systems solve these problems (or rather, don't) at a slight
expense to user experience. Availability data is pulled and presented to
the user (and may be occasionally refreshed, using something like the
server-to-client techniques mentioned above, or a simple timer). However,
availability isn't guaranteed until the actual reservation is placed and
confirmed -- there is a possibility the chosen seats will no longer be
available and the reservation will fail. If that happens, the user can
cancel transaction or choose new seats from an updated list. This works
well enough for slow moving reservations, like airlines.

When the reservations are moving fast, often a temporary hold is used. The
idea behind that is simple: the desired number of automatically chosen
(typically "best available") seats are temporarily put on hold for the user,
before anything else happens. The seats being held won't be confirmed for
anyone else until the hold is released by the first user successfuly
reserving a different selection (or hold expiring, user ending the session,
and so forth).

In the worst case (massive rush) scenario, this results in everyone making a
few attempts at selections, but most users, especially toward the end,
ultimately ending up with their automatically assigned seats. That beats
none, which could otherwise easily happen while the user is repeatedly
forced to change their selections until there's nothing left.

Hope that helps,

--
Chris Priede