Synchronisation de l'application de réservation C#/asp.net

Question

Je développe une application de réservation d'événements et j'ai de la difficulté à trouver comment gérer le processus de réservation. Je connais les transactions db et un peu de verrouillage mais j'ai beaucoup de règles à valider avant qu'une réservation puisse être validée et je m'inquiète des goulets d'étranglement au niveau des performances.

Voici un résumé de ce qui se passe:

• Un événement a un nombre maximum de créneaux horaires
• Un utilisateur peut réserver une place dans l'événement
• Chaque utilisateur dispose d'un compte avec de l'argent et chaque événement coûte un certain montant

Compte tenu des paramètres ci-dessus, les règles commerciales suivantes sont ce que je dois valider pour une réservation de lieu:

• L'utilisateur n'a pas déjà réservé une place pour cet événement
• L'utilisateur dispose de fonds suffisants pour réserver l'événement
• L'événement a au moins un point disponible
• L'événement ne sont pas en conflit avec d'autres les événements que l'utilisateur a réservé (pas tant d'un problème que je peux vérifier lors de l'affichage de la page et cacher cet événement de l'utilisateur)

Mon principal souci est que si je tire toutes les informations de la db up avant (ie Event, User, Account, et Bookings existants) qu'au moment où j'effectue toute la validation et que je viens valider la nouvelle réservation, l'état du système aura probablement changé (ie quelqu'un a réservé la dernière place, l'argent a quitté mon compte, etc). Si je devais verrouiller les tables de code/base de données autour de ce processus de réservation, alors j'ai potentiellement (??) obtenu le verrou pendant un certain temps affectant d'autres opérations dans le système et causant des problèmes de performance aux heures de pointe. Quelqu'un peut-il suggérer une approche par laquelle je peux gérer ou au moins limiter ces préoccupations.

Je construis une application asp.net en C# et utilisant le serveur sql 2005.

Answer 1

Je pense qu'un bon exemple de regarder comment Ticketmaster réserve des places pour des billets qui en peuvent être achetés. Ils vous disent que vous avez tant de minutes jusqu'à ce que les sièges soient remis dans l'inventaire. Il pousse l'acheteur à prendre une décision ou quelqu'un d'autre aura une chance aux sièges. C'est vraiment votre plus gros obstacle. Pour ce qui est de vérifier les règles de gestion, vous devrez le faire. Il n'y a pas de magie autour de ce qui doit être fait là-bas. Si vous avez besoin des données pour valider une règle, c'est ce que vous devez faire. Avec une cartographie et une esquisse appropriées, vous pouvez trouver les gains d'efficacité. J'espère que cela a répondu à votre question.

Bonne chance!

Answer 2

Une solution:

1. préemptive réserver la place (avec un statut de "tenir").
2. Valider.
3. Si la réservation ne peut être tenue en raison de règles de gestion, supprimez-le.Si non, changez le statut en "réservé"

Answer 3

Si vous retournez aux années 80 et lisez la littérature publiée sur le sujet du traitement des transactions, vous constaterez que l'un des exemples les plus discutés a été les systèmes de réservation des compagnies aériennes. Et pour cause, car c'est l'un des sujets d'OLTP qui a exposé tous les problèmes liés au traitement des transactions: correction, troughput, contention, deadlocks. Ce que vous décrivez est un problème très similaire, mais au lieu de sièges d'avion, vous avez des créneaux horaires. Alors oui, vous aurez tous ces problèmes.

Il n'y a pas de poussière de lutin magique. C'est un problème difficile. Mais il y a quelques lignes directrices:

• Oublieux Fred ne peut pas verrouiller un emplacement pour toujours. Oublieux Fred est l'utilisateur qui ouvre l'écran de réservation, choisit un siège, puis va déjeuner sans terminer la transaction. Si cela est autorisé, le système «fuira» lentement les emplacements qui ne sont pas utilisés.
• Les verrous de base de données sont trop chers pour être maintenus en attente de la saisie par l'utilisateur.
• Le débit ne peut être atteint qu'avec des verrous granulaires.
• La logique métier ne doit pas tenter de mises à jour concises sur les éléments corrélés.
• Tout ce qui est affiché à l'utilisateur doit être considéré comme «provisoire».
• L'interface utilisateur doit être préparée pour gérer les conflits de mise à jour.
• La logique de mise à jour doit toujours suivre la même hiérarchie (par exemple, si la logique de mise à jour est Account-> User-> Event-> Booking, une transaction rogue essayant de mettre à jour Booking-> Event-> User provoque des blocages).

Et En fait, il y a une approche qui limite ces préoccupations: workflow processing soutenu par transactional queues qui tirent parti correlated items exclusive lock out. Pas forcément votre tâche ASP quotidienne, alors je vous recommande de rester fidèle à ce que vous savez.