Yeni Kayıt
Konudaki Resimler
< Bu ileti mobil sürüm kullanılarak atıldı > |
Hızlı 
Bildirim
Birden fazla kullanıcı aynı satırda işlem yapmak isterse?
Sıcak Fırsatlarda Tıklananlar
Editörün Seçtiği Fırsatlar
Kono USB Şarj Portlu Seyahat Dizüstü Bilgisayar Sırt Çantası Suya Dayanıklı İş Bilgisayar Çantası Okul Çantası Kadın Erkek Günlük Sırt Çantası 15,6 İnç Dizüstü Bilgisayara Uygun, gri, M : Amazon.com.tr: Bilgisayar
https://www.amazon.com.tr/dp/B07ZVLPKZ7
8 sa. önce paylaşıldı
Daha Fazla 
Bu Konudaki Kullanıcılar:
Daha Az 
1 Misafir - 1 Masaüstü
Giriş
Mesaj
-
-
Bu senin degil, veri tabaninin problemi ( Eger veritabani yazmiyorsan ). ACID prensiplerini inceleyebilirsin.
https://en.wikipedia.org/wiki/ACID
---
Eger uygulaman bu durumun dogru calismasina bagimliysa , ki database'ler zaten bunun duzgun calismasi uzerine kurulu; bunu uygulama seviyesinde de forse edebilirsin.
Eger tek makinede tek instance uzerinde calisiyorsa lock mekanizmasi kullanarak; tek makine cok instance ise memory share ile ; cok makine cok instance ise cluster cache kullanarak.
Eger bu bir odev ise , semafor falandir muhtemelen hocanin ogretmeye calistigi sey. Programlama diline gore nasil implemente edildigini ogrenip yapabilirsin.
https://en.wikipedia.org/wiki/Semaphore_(programming)
< Bu mesaj bu kişi tarafından değiştirildi Mephalay -- 20 Eylül 2017; 22:15:36 >
< Bu ileti tablet sürüm kullanılarak atıldı >
-
quote:
Orijinalden alıntı: Mephalay
Bu senin degil, veri tabaninin problemi ( Eger veritabani yazmiyorsan ). ACID prensiplerini inceleyebilirsin.
https://en.wikipedia.org/wiki/ACID
---
Eger uygulaman bu durumun dogru calismasina bagimliysa , ki database'ler zaten bunun duzgun calismasi uzerine kurulu; bunu uygulama seviyesinde de forse edebilirsin.
Eger tek makinede tek instance uzerinde calisiyorsa lock mekanizmasi kullanarak; tek makine cok instance ise memory share ile ; cok makine cok instance ise cluster cache kullanarak.
Eger bu bir odev ise , semafor falandir muhtemelen hocanin ogretmeye calistigi sey. Programlama diline gore nasil implemente edildigini ogrenip yapabilirsin.
https://en.wikipedia.org/wiki/Semaphore_(programming)
Teşekkür ederim hocam ödev değil.
Bir web uygulaması üzerinde çalışıyorum beğeni butonu yaparken aklıma takıldı. Beğen butonunda çok sorun olmaz ama daha farklı bir projede nasıl çözerim onu merak etmiştim.
< Bu ileti mobil sürüm kullanılarak atıldı >
-
Bildiğim kadarıyla databaseler her ne kadar aynı anda birçok isteğe cevap veriyor gibi dursa da aslında derinlerde sorgular bir sıraya dizilerek işlem yapılıyor. İki işlem aynı zamanda gibi görünse de çok çok çok kısa zaman farkı olacağı için önce gelen işlem önce sonuçlanıyor. Yani son yazılan değer geçerli kalıyor.
Pratik uygulamada Beğeni üzerinden gidelim. Beğeni sayıları genelde beğenen kişileri de içerdiği için aslın database de sayı olarak biriktirilmiyor. Onun yerine bağlı tablolar olarak işlem görüyor. Bu durumda toplam beğeniyi bulmak için tüm beğeniler sorgulanıp ilgili mesaj için olanlar filtreleriyor ve kalan sorgudaki satır sayısına bakılıyor. Bu durumda beğenen kişi sayısı değişse dahi yanlış hesaplama gibi bir durum söz konusu olmuyor.
Sayı olarak tutmak için bir sıralama(queue) oluşturup artırma bildirimlernizi bu sıralamaya eklemeniz gerekmekte. Sonrasında sıralama fonksiyonu her ek için sayıyı tek tek yükseltebilir. Böylelikle pekçok kaynaktan gelen sorgu isteği tek girişe yönlendirilerek olası hatalar giderilir.
< Bu ileti mini sürüm kullanılarak atıldı >
-
write lock ile o satırı kitlersin.
Transaction desteği olan veritabanı motorları destekler bunu.
MySQL de innodb gibi -
quote:
Orijinalden alıntı: CarnageTR
Bildiğim kadarıyla databaseler her ne kadar aynı anda birçok isteğe cevap veriyor gibi dursa da aslında derinlerde sorgular bir sıraya dizilerek işlem yapılıyor. İki işlem aynı zamanda gibi görünse de çok çok çok kısa zaman farkı olacağı için önce gelen işlem önce sonuçlanıyor. Yani son yazılan değer geçerli kalıyor.
Pratik uygulamada Beğeni üzerinden gidelim. Beğeni sayıları genelde beğenen kişileri de içerdiği için aslın database de sayı olarak biriktirilmiyor. Onun yerine bağlı tablolar olarak işlem görüyor. Bu durumda toplam beğeniyi bulmak için tüm beğeniler sorgulanıp ilgili mesaj için olanlar filtreleriyor ve kalan sorgudaki satır sayısına bakılıyor. Bu durumda beğenen kişi sayısı değişse dahi yanlış hesaplama gibi bir durum söz konusu olmuyor.
Sayı olarak tutmak için bir sıralama(queue) oluşturup artırma bildirimlernizi bu sıralamaya eklemeniz gerekmekte. Sonrasında sıralama fonksiyonu her ek için sayıyı tek tek yükseltebilir. Böylelikle pekçok kaynaktan gelen sorgu isteği tek girişe yönlendirilerek olası hatalar giderilir.
Teşekkür ederim hocam beğeni özelliğini dediğiniz gibi yapmıştım zaten daha farklı projeler için merak etmiştim.
< Bu ileti mobil sürüm kullanılarak atıldı >
-
quote:
Orijinalden alıntı: Delifisek.Tux
write lock ile o satırı kitlersin.
Transaction desteği olan veritabanı motorları destekler bunu.
MySQL de innodb gibi
Write Lock buna nasıl engel olabilir hocam veriyi çeker çekmez mi kitlemek gerekecek bu nasıl bir çözüm olacak sonuçta stoğa 2 eklemek gerekirken yine 1 eklenmiş olmayacak mı?
A kişisi çekti 5 verisini bekliyor oyalanıyor bu sırada B kişisi de çekti aynı veriyi ikisi de bir ekledi ve yolladı ikisi de 6 yolladı yani.
hadi A kisisi veriyi çekince kilitledik diyelim satırı. 6 verisini yolladı kilidi kaldırdık. Ardından B kişisi de çektiği 5 verisini işledi 1 ekledi 6 olarak yolladı. Sonuçta o satır 7 olması gerekirken 6 kaldı. Bunu farklı bir sayfaya yollayıp artış miktarlarını bekletip birbirine ekleyip veritabanına yollamak mı gerekir.
< Bu ileti mobil sürüm kullanılarak atıldı >
-
Anlık olarak yaparsın.
yani satırı kilitersin
veri update edilene kadar başka kimse ne okur ne yazar.
senin işin bitince kilit açılır bir sonraki arkadaş devam eder.
bu esnada kilitleyen hariç herkes bekler. -
Hocam Selamlar,
Buradaki arkadaşlarda açıklamışlar, ilişkisel veritabanları ACID prensibine göre çalışır ve data tutarsızlığının önüne geçmek için bir lock mekanizması kullanır. Hatta bu lock mekanizması kayıt için değil tablo için çalışır. Aynı tablo üzerine gelen kullanıcılar birbirlerinin işlerinin bitmesini beklemek durumundadır.
Durumun önüne geçmek için tablo locklandığında aynı tablo üzerine işlem yapmak isteyen kullanıcıya exception fırlatmak olabilir uygulama katmanında :)
Kolay Gelsin,
İyi Forumlar. -
quote:
Orijinalden alıntı: hseyindemirr
Hocam Selamlar,
Buradaki arkadaşlarda açıklamışlar, ilişkisel veritabanları ACID prensibine göre çalışır ve data tutarsızlığının önüne geçmek için bir lock mekanizması kullanır. Hatta bu lock mekanizması kayıt için değil tablo için çalışır. Aynı tablo üzerine gelen kullanıcılar birbirlerinin işlerinin bitmesini beklemek durumundadır.
Durumun önüne geçmek için tablo locklandığında aynı tablo üzerine işlem yapmak isteyen kullanıcıya exception fırlatmak olabilir uygulama katmanında :)
Kolay Gelsin,
İyi Forumlar.
Teşekkürler iyi forumlar :)
< Bu ileti mobil sürüm kullanılarak atıldı > -
quote:
Orijinalden alıntı: hseyindemirr
Hocam Selamlar,
Buradaki arkadaşlarda açıklamışlar, ilişkisel veritabanları ACID prensibine göre çalışır ve data tutarsızlığının önüne geçmek için bir lock mekanizması kullanır. Hatta bu lock mekanizması kayıt için değil tablo için çalışır. Aynı tablo üzerine gelen kullanıcılar birbirlerinin işlerinin bitmesini beklemek durumundadır.
Durumun önüne geçmek için tablo locklandığında aynı tablo üzerine işlem yapmak isteyen kullanıcıya exception fırlatmak olabilir uygulama katmanında :)
Kolay Gelsin,
İyi Forumlar.
bu arkadaşın derdini çözmez. arkadaşın anlatmak istediği sanırım şu:
-a kaydı okudu
-b kaydı okudu
-a değişiklikler yaptı ve kaydetti
-b değişiklikler yaptı ve kaydetti
işte b kaydedememeli. kayıt güncel değil hatası vermeli. optimistic concurrency, pessimistic concurrency konusu bu. temel mantığı şöyle; kaydı güncellemeden önce kayıt hala ilk okuduğun gibi mi kontrol edilir. eğer öyleyse sıkıntı yok. değişmişse hata patlatılır. aşağıda bununla ilgili bir yazı var:
https://docs.microsoft.com/en-us/aspnet/web-forms/overview/data-access/editing-inserting-and-deleting-data/implementing-optimistic-concurrency-cs
< Bu mesaj bu kişi tarafından değiştirildi beyinsis -- 26 Eylül 2017; 9:11:27 >
-
quote:
Orijinalden alıntı: beyinsis
quote:
Orijinalden alıntı: hseyindemirr
Hocam Selamlar,
Buradaki arkadaşlarda açıklamışlar, ilişkisel veritabanları ACID prensibine göre çalışır ve data tutarsızlığının önüne geçmek için bir lock mekanizması kullanır. Hatta bu lock mekanizması kayıt için değil tablo için çalışır. Aynı tablo üzerine gelen kullanıcılar birbirlerinin işlerinin bitmesini beklemek durumundadır.
Durumun önüne geçmek için tablo locklandığında aynı tablo üzerine işlem yapmak isteyen kullanıcıya exception fırlatmak olabilir uygulama katmanında :)
Kolay Gelsin,
İyi Forumlar.
bu arkadaşın derdini çözmez. arkadaşın anlatmak istediği sanırım şu:
-a kaydı okudu
-b kaydı okudu
-a değişiklikler yaptı ve kaydetti
-b değişiklikler yaptı ve kaydetti
işte b kaydedememeli. kayıt güncel değil hatası vermeli. optimistic concurrency, pessimistic concurrency konusu bu. temel mantığı şöyle; kaydı güncellemeden önce kayıt hala ilk okuduğun gibi mi kontrol edilir. eğer öyleyse sıkıntı yok. değişmişse hata patlatılır. aşağıda bununla ilgili bir yazı var:
https://docs.microsoft.com/en-us/aspnet/web-forms/overview/data-access/editing-inserting-and-deleting-data/implementing-optimistic-concurrency-cs
İşte bu hocam çok teşekkürler
< Bu ileti mobil sürüm kullanılarak atıldı >
Sayfa:
1
Ip işlemleri
Bu mesaj IP'si ile atılan mesajları ara Bu kullanıcının son IP'si ile atılan mesajları ara Bu mesaj IP'si ile kullanıcı ara Bu kullanıcının son IP'si ile kullanıcı ara
KAPAT X
Bu mesaj IP'si ile atılan mesajları ara Bu kullanıcının son IP'si ile atılan mesajları ara Bu mesaj IP'si ile kullanıcı ara Bu kullanıcının son IP'si ile kullanıcı ara
KAPAT X
