Gestion d'un conflit lors d'une réservation

Version imprimable

Bonjour à tous et à toutes ..
Voici mon problème, je souhaite gérer un conflit lors d'une réservation.
Cas :
JE dispose de plusieurs tables
Une table emplacement qui contient les emplacements de parking, le champ PlaceFor est là pour indiquer si il s'agit d'une reservation ou d'un abonnement
Code:

1 2 3 4 5 6 CREATE TABLE [dbo].[Emplacement]( [EmplacementId] [int] IDENTITY(1,1) NOT NULL, [ParkingId] [int] NOT NULL, [Status] [bit] NOT NULL, [num] [int] NOT NULL, [PlaceFor] [char](1) NULL,)
D'une table réservation
Code:

1 2 3 4 5 6 7 CREATE TABLE [dbo].[Reservation]( [ReservationId] [int] IDENTITY(1,1) NOT NULL, [StartDate] [datetime2](7) NOT NULL, [EndDate] [datetime2](7) NOT NULL, [EmplacementId] [int] NOT NULL, [ClientId] [int] NOT NULL )
Mon problème est le suivant.
J'aimerais gérer en asp.net MVC le cas suivant.
Disons qu'il ne reste qu'une place est que 2 personnes soient connectées en même temps sur mon site à la recherche d'un emplacement?
Je voudrais gérer le conflit entre les 2 c'est à dire attribuer la dernière place restante à la première personne qui aura validée son choix.
Merci de m'aiguiller vers la bonne solution. Transaction , concurrency etc ...

Si je comprend biens dans ton cas tu veux eviter un double insert dans la table "Reservation" ?
Tu pourrais faire une store proc du genre :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
create procedure SP_Reservation
  @startdate datetime,
  @enddate datetime,
  @emplacementid int,
  @clientid int,
  @inserted bit output
as
begin
  Insert into Reservation (startdate,  enddate,  emplacementid,  clientid)
  select 
  @startdate,
  @enddate,
  @emplacementid,
  @clientid
  from Emplacement e
 where e.emplacementid=@emplacementid and not exstis(select null from reservation r where r.EmplacementId = e.EmplacementId --and [date ou autre critères]
select @inserted = cast(case when @@rowcount = 0 then 0 else 1 end as bit)
end

Code non testé, c'est juste une idée.

05/07/2017, 09h44
Pol63

une transaction verrouille les lignes modifiées, à savoir si tu fais un update/insert/delete, la ligne ne peut être ni modifiée ni lue (par défaut, car on peut quand même dans certains cas) par un autre, tant que tu n'es pas sorti de la transaction
c'est un verrou qui fait attendre ceux qui veulent accéder à la ligne

ca n'empeche donc pas de vérifier que ce que tu veux faire est autorisé comme avec la requete de Dokho1000 qui fait un insert avec un where qui vérifie
(tu n'es pas obligé de faire une procédure stockée, le commandtext peut contenir plusieurs instructions)
par contre je ne suis pas sur qu'un insert suivi d'un where not exists n'est pas exécuté en 2x auquel cas le select pour retourner que c'est faisable et l'insert serait fait après, donc potentiellement un problème si 2 se croisent au mauvais moment, un expert sql server pourrait confirmer ça

il est aussi possible de gérer ça en partie .net avant d'accéder à la base de données
si tu as une méthode qui s'occupe de faire les inserts, tu peux mettre un lock qui fait qu'un seul thread pourra y accéder à la fois (c'est chacun son tour, les autres en cas de simultané attendent)
là tu as le temps de vérifier que ca n'est pas déjà pris en base, puis de faire ton insert
l'inconvénient c'est que si tu as 100 clients qui font des résa en même temps ca va les ralentirs parfois pour rien, alors qu'sql server pourrait en traiter plein à la fois sans s’emmêler les pinceaux
si tu as la liste des résa en ram et indexé (dictionary par exemple) par contre ca devient très rapide à tester donc le lock ne ralentira pas spécialement, par contre il faut être sûr de son cache, et donc de son code (ca fait plus de lignes qu'en sql)

le mieux reste quand même de structurer ses tables pour pouvoir mettre un index unique, lui te garantira que même si tu as mal codé, ca ne pourra pas arriver
avec ton créneau horaire ca me semble difficile si plusieurs jours peuvent arriver entre debut et fin
par contre si pour chaque jour tu mets une entrée dans la table (à savoir 3 jours = 3 lignes dans la table) alors tu peux mettre un index unique sur debut+fin+idemplacement et là c'est le sgbdr qui te jetteras si tu essayes
(ca n'empeche pas de tester au mieux, coder en réaction aux erreurs n'est pas une bonne pratique)