




T Anında Web Servis Kaç Kayıt İşliyor - Uzman Bakış Açısı Gerek
-
Selamlar,
İlginç bir problemim var. Bakış açınızı merak ediyorum.
Bir web servis var. Bu 10 larca farklı kanaldan kullanılıyor amacı tek bir tabloya insert etmek. Öyle ki,
1- t anında 100 farklı yerden web servis call edilir.
2- Web servisin insert ettiği tablonun PK sı malesef GETDATE() yani t anında 100 insert işlemi için (SANIRIM) aynı zamanı üretiyor ve dup rec hatası oluyor.
3- T anında 100 insert geldiğinde bunlar duplicate ediyor bunu önlemek için getdate() 10 kere filan üretiliyor. Her birinde yeni bir date üretiliyor. Bu bence çok yanlış increment bir yapı yok. 10 kere üretilmesine rağmen dup rec yine olabiliyor.
Burada akışı şöyle mi?
1- Insert işlemi geldi.
2- Üretilen getdate() zamanı bir öncekiyle çakıştı.
3- 10 kere daha getdate() üretmeyi deniyor ve bunu insert etmek istiyor yine de dup rec alabiliyor.
4- Gelen bu işlem içeri insert edilmek için çalışırken web servis call ile yeni bir işlem daha geldiğinde WEB SERVİS NASIL ÇALIŞIYOR? İçeri insert etmek istediği kaydı mı önce halleder yoksa thread üzerinde yeni bir akış mı başlatır.
Bunla ilgili makale/ yazı vs varsa paylaşabilir misiniz? Bu dup rec i çözmem gerekiyor.
Teşekkürler.
-
Eğer çalıştığın banka için yapıyorsan bunu neden ESB veya api gateway üzerinden almıyorsun bağlantıları. Bu ürünler zaten transactionların geldiği yeri saati açık kaldığı bağlantı süresini felan gayet rahat ölçer. Olmadı apm varsa oradan alabilirsin o da mı olmadı api management patternlerinde bir yerde bahsediliyor bu konu. Bulursam atarım.
-
sandman bunu yazdı
Eğer çalıştığın banka için yapıyorsan bunu neden ESB veya api gateway üzerinden almıyorsun bağlantıları. Bu ürünler zaten transactionların geldiği yeri saati açık kaldığı bağlantı süresini felan gayet rahat ölçer. Olmadı apm varsa oradan alabilirsin o da mı olmadı api management patternlerinde bir yerde bahsediliyor bu konu. Bulursam atarım.
Selam konu banka projesi değil hocam. Ben işleyişi anlamaya çalışıyorum.
-
Anladım,
Her biri farklı yerden geliyorsa get requiest origin ile geldiği yeride alıp ayrıştırmaya çalışabilirsin veya araya bir middleware katmanı yazıp, webapi her çağrıldığında o requiest için ayrı bir id yaratıp onunla yazsan?
-
Tek cekirdekli islemci kullanip, en kucuk zaman biriminde bi islemi gerceklestiricek sekilde tasarlarim, gerektiginde yeni islemleri bekletirim, queue uzerinde beklerler
Madem adam kekoluk yapip pk yi getdate yapti, bunu da kabul eder
-
getdate() + random veri şeklinde kayıt etsen?
01.01.2018 12:23:34:100 - asdh32şkjf
sonra yine tarih saat olarak kullanabilrisin sanırım.Konuyla uzaktan yakından alakam yoktur, saçmaysa da saçma napalım :)
-
NoktaliVirgul bunu yazdı
getdate() + random veri şeklinde kayıt etsen?
01.01.2018 12:23:34:100 - asdh32şkjf
sonra yine tarih saat olarak kullanabilrisin sanırım.Konuyla uzaktan yakından alakam yoktur, saçmaysa da saçma napalım :)
Önceki zaman veya sonraki zaman ile illaki çakışacaksın. Kaçış yok bu durumdan.
-
sandman bunu yazdı
Anladım,
Her biri farklı yerden geliyorsa get requiest origin ile geldiği yeride alıp ayrıştırmaya çalışabilirsin veya araya bir middleware katmanı yazıp, webapi her çağrıldığında o requiest için ayrı bir id yaratıp onunla yazsan?
00:00 da A sisteminden gelen kayıtları işlerken 00:01 de B sisteminden gelen kayıtları (00:00 da ki işlem daha bitmemişken) paralelinde işliyor mudur? MSSQL , C#'ın buradaki yönetimi nasıl acaba...
Yoksa bunları queue de mi tutuyor onu araştııyorum.
PK yı değiştirme şansım yok malesef getdate() kalmaya devam edecek ama gelen insertleri dup rec'e yol açmadan içeri insert edebilmeliyim.
-
Queue yu sen araya alacaksın rabbitmq veya microsoft un msmq sen oraya sıralıcaksın kayıtları sonra baska bir servis ile okuyup insert edersin cakısmada yasamazsın bence en baba hareket timestamp kullanmak olur getdate yerine
-
transaction kullanabilir misin? peki tablo yapın müsait mi?
-
zeybekustasi bunu yazdıNoktaliVirgul bunu yazdı
getdate() + random veri şeklinde kayıt etsen?
01.01.2018 12:23:34:100 - asdh32şkjf
sonra yine tarih saat olarak kullanabilrisin sanırım.Konuyla uzaktan yakından alakam yoktur, saçmaysa da saçma napalım :)
Önceki zaman veya sonraki zaman ile illaki çakışacaksın. Kaçış yok bu durumdan.
Problem duplicate kayıt olmasın diye değil mi :)
Önceki sonraki kaydı bilmem gerekiyor diyorsan şimdi yatıyorum. uykumda düşüneyim :)