Veri Transferi Yönetimi

[thelvaci]

@thelvaci hocam haklısın ama Android yakasında olduğunu varsayalım o da sıkıntı. Gerçi konumuz android ile alakalı mı ne kadar alakalı sadece bir beyin fırtınası için yazıyorum.

O zaman WebServices destekli ara bir sunucu veya web sitesi eklemek zorunluluğu velhasıl benzer sıkıntı onda da olacaktır.

Veri gönderimi sırasında hata olursa zaten sistem yakalamıyor mu ? Transaction %100 tamam olunca veritabanına düşüyor. Aksi bir durum ile karşılaşmadım ama risk görüyorsanız ikinci bir kontrol ile bu durum kontrol altına alınabilir diye değerlendiriyorum.

Yanlış mı düşünüyorum ?

Merhaba üstadım, örnek olarak SQL Server'ı verelim; diyelim ki döngü ile SQL Server üzerindeki 3 adet sp çalıştıracak olsun. 1nci sp isteğini server'a gönderdik, bağlantımız var; ikinciyi gönderdik bağlantımız var; 3üncüyü gönderir iken bağlantımız koptu. Bu durumda; 1 ve 2nci sp'ler Sql server tarafında execute olmaya devam ediyorlardır. Diyelim ki döngümüzden önce bir transaction başlattık; bu durumda bağlantımız koptuktan sonra transaction'ı rollback yada commit etme imkanımız olmayacak. Sql Server'da o transaction açık olarak kalacak(bu da başka sorunlara neden olabilir ya neyse konu bu değil); eğer Sql Server isteği gönderen connection'ın artık var olmadığını anlayabilir ise transaction'u rollback etmeye çalışacak ama transaction isimsiz olduğu(savepoint) için hangisini rollback edeceğini yada edip etmemesi gerektiğini bilemeyecek. Eğer şanslı isek Sql Server transaction'ı rollback edecek. Beklenen ve genelde olan durum bu elbette. Lâkin bir transaction'da başlatılmamış olabilir.

Bunu kısaca şu şekilde deneyebilirsiniz, network ortamında pek çok makinanız vardır. Uzak bir sql server üzerinde bir sp yazın içinde WAITFOR ile 10 sn. bekleyen bir kodunuz olsun, hemen ardından bir tabloya kayıt girsin sp'niz. Kendi bilgisayarınızdan uzak sunucuya bağlanın ve bu sp'yi çalıştırın, ardından da makinanızın network bağlantısını kesin. Göreceksiniz ki; sql server sp'yi execute etmeye devam edecek. Server'a iş emri gitti ise o emir tamamlanacak. Tabii bu gibi durumlarda da hele hele transactional bir aktarım kullanılmıyor ise; neler olabileceğini hayal edersiniz

Bu aktarım mevzuları gerçekten de çok derin; M$ boşuna replication diye bir mekanizma çıkartmamış ama onun da kendi içinde bir dünya sıkıntısı ve zorlukları mevcut. Arkadaşımıza önerdiğim hususu inceleyebilir ise MSMQ'nun bu tarz işler için biçilmiş kaftan olduğunu gözlemleyebilir sanıyorum.

[mrmarman]

Merhaba hocam konuştuğum konu DATASNAP ve REST önce bunun altını çizmek gerek.

Uzak sunucuya veri gönderirken (INSERT, SELECT INTO, UPDATE) ben daima SQL kısmını Delphi yakasında yazıyorum. Yani karşı tarafa bir şey bırakmıyorum. Dolayısı ile transaction bu talep total olarak gitti mi gitmedi mi şeklinde çalışıyor. DataSnap da zaten öyle çalışıyor.

Karşı tarafa gönder gönder gönder gönder sonra COMMIT et olayında dediğiniz olabilir ama şu anki çalışma koşullarımda bu durum söz konusu değil. O zaman mesajda belirttiğiniz şekilde işi şansa bırakmış oluyorum. Zaten böyle kesinti yaşanacak mobil platformlarda kimse MSSQL vs. direkt veri bağlantısını tercih etmez ve etmemelidir. Bunun altını iki defa çiziyorum.

Genel olarak MSMQ zaten MS-SQLServer 'in bu yumuşak karınını biraz bertaraf etmek için Microsoft'un başarılı bir çabası olduğu açık olarak görünüyor. Dolayısı ile mutlaka bilinmesi gereken bir husus. Verdiğiniz bilgiler için teşekkürler.

[thelvaci]

Rica ederim üstad. Konu içeriğinde merkez<->şube iletişimi olduğu için bu tarz bir yönlendirmede bulunmak istedim. Neticede online aktarım metodolojilerinin hepsi low level winsock'a uğruyor ve orada da TCP kullanıyor; malum TCP connection bağımlı ve handshaking gerektiriyor. UDP ise güvenli değil, paketlerin hedefe ulaşmama ihtimali var. Bu nedenle bu tarz işlemler için offline/yarı online çözümler üzerine gitmek ilerisi için çok faydalı olabilir. M$'un MSMQ'su ile sınırlı değiliz elbette; ben onu işletim sistemine gömülü geldiği için örnekledim; yoksa pek çok mesaj tabanlı offline iletişim tool'u mevcut(RabbitMQ gibi).

Kısaca, LAN yada WAN ortamında iken iki bilgisayar arasında güvenli ve kayıpsız veri aktarımının online olarak basit ve stabil bir yolu yok. Çok çeşitli nedenlerden ötürü iletişim sekteye uğrayabilir ve bu durumda programcının bir çok kontrol yapması gerekir. Ama tabii, "saldım çayıra mevlam kayıra" metodu da benimseniyor olabilir O zaman söylediklerimi söylemediğimi varsaysın arkadaşlarım

[emrahgs]

Hocam önerileriniz İçin Çok Teşekürler, Hepsini Araştırıyorum Teker Teker;
@tthelvaci hocamında dediği gibi "Bu aktarım mevzuları gerçekten de çok derin"
Bir Çok Yöntem Üzerinde Üzerinde Araştırma Yapıp En Uygun Olanını Seçmeliyim

Tabi Bura da En Güvenli En Hızlı En Sorunsuz Olan Her Zaman En Doğru Tercih Olamayabiliyor Reel Hayatta.
Müşterilerin Teknik Alt Yapısı, Sistemi Kuracak Bayiilerin Bilgi Düzeyi,
Bu Proje İçin Size Verilen Süre, İş Gücünüz Gibi Bir Çok Etken Yöntem Belirlemede Etkili Oluyor.

[muratcelik64]

USE PROJELERX
GO
CREATE DATABASE ProjelerX_dbss1800 ON
( NAME = ProjelerX_Data, FILENAME =
'E:\PROJELERX\SNAPSHOT\ProjelerX_dbss1800.ss' )
AS SNAPSHOT OF ProjelerX;
GO

PROJELERX -> DB adı
ProjelerX_dbss1800 -> Yeni oluşturulacak olan Snapshot DB adı
ProjelerX_dbss1800.ss' -> HDD üzerinde oluşturulan DB adı


SQL Server üzerinde böyle bir ayarlama yapıldığında gölge bir DB oluşturulmaktadır. Bunun faydası ise son kullanıcının bu gölge DB üzerinde çalışması, tüm kayıt işlemlerini yapan ilk kullanıcıların ise rahatça DB üzerinde işlemlerini görmesini sağlamaktadır. Günlük veya haftalık yedeklemelerle bu gölge DB nin içeriğide güncellenmiş olur.