Bir okuma işlemini gerçekleştirmeli veya geri almalı mıyım?

İzolasyon seviyesini belirtebilmem için bir işlem içinde yürüttüğüm bir okuma sorgum var. Sorgu tamamlandıktan sonra ne yapmalıyım?

• İşlemi tamamla
• İşlemi geri alın
• Hiçbir şey yapmayın (bu, kullanım bloğunun sonunda işlemin geri alınmasına neden olur)

Her birini yapmanın sonuçları nelerdir?

using (IDbConnection connection = ConnectionFactory.CreateConnection())
{
    using (IDbTransaction transaction = connection.BeginTransaction(IsolationLevel.ReadUncommitted))
    {
        using (IDbCommand command = connection.CreateCommand())
        {
            command.Transaction = transaction;
            command.CommandText = "SELECT * FROM SomeTable";
            using (IDataReader reader = command.ExecuteReader())
            {
                // Read the results
            }
        }

        // To commit, or not to commit?
    }
}

DÜZENLEME: Soru, bir işlemin kullanılması gerekip gerekmediği veya işlem seviyesini belirlemenin başka yolları olup olmadığı değildir. Buradaki soru, herhangi bir değişiklik yapmayan bir işlemin taahhüt edilmesi veya geri alınmasıdır. Performans farkı var mı? Diğer bağlantıları etkiliyor mu? Başka fark var mı?

Sen taahhüt et. Dönem. Başka mantıklı bir alternatif yok. Bir işlem başlattıysanız, kapatmalısınız. Kaydetmek, sahip olabileceğiniz tüm kilitleri serbest bırakır ve ReadUncommitted veya Serializable yalıtım düzeylerinde de aynı derecede mantıklıdır. Örtük geri dönüşe güvenmek - belki teknik olarak eşdeğer olsa da - sadece kötü bir biçimdir.

Bu sizi ikna etmediyse, kodunuzun ortasına bir güncelleme ifadesi ekleyen ve meydana gelen ve verilerini kaldıran örtük geri dönüşü izlemesi gereken bir sonraki kişiyi hayal edin.

Hiçbir şeyi değiştirmediyseniz, COMMIT veya ROLLBACK kullanabilirsiniz. Her ikisi de edindiğiniz okuma kilitlerini serbest bırakacak ve başka herhangi bir değişiklik yapmadığınız için eşdeğer olacaktır.

Bir işleme başlarsanız, en iyi uygulama her zaman onu yapmaktır. Kullanım (işlem) bloğunuzun içine bir istisna atılırsa, işlem otomatik olarak geri alınacaktır.

IMHO, işlemlerde salt okunur sorguları sarmalamak mantıklı olabilir çünkü (özellikle Java'da) işlemin "salt okunur" olmasını söyleyebilirsiniz, bu durumda JDBC sürücüsü sorguyu optimize etmeyi düşünebilir (ancak buna gerek yoktur, yani kimse INSERTyine de bir düzenleme yapmanıza engel olacaktır ). Örneğin, Oracle sürücüsü, salt okunur olarak işaretlenmiş bir işlemdeki sorgularda tablo kilitlerini tamamen önleyecektir, bu da yoğun şekilde okuma güdümlü uygulamalarda çok fazla performans elde eder.

İç içe geçmiş işlemleri düşünün .

Çoğu RDBMS, iç içe geçmiş işlemleri desteklemez veya bunları çok sınırlı bir şekilde taklit etmeye çalışır.

Örneğin, MS SQL Server'da, bir iç işlemdeki geri dönüş (gerçek bir işlem değildir, MS SQL Server yalnızca işlem seviyelerini sayar!), En dıştaki işlemde (gerçek işlem olan) gerçekleşen her şeyi geri alır .

Bazı veritabanı sarmalayıcıları, bir iç işlemdeki geri dönüşü, en dıştaki işlemin tamamlanmış veya geri alınmış olmasına bakılmaksızın, bir hatanın oluştuğunun bir işareti olarak kabul edebilir ve en dıştaki işlemdeki her şeyi geri alabilir.

Dolayısıyla COMMIT, bileşeninizin bazı yazılım modülleri tarafından kullanıldığını göz ardı edemediğinizde güvenli yoldur.

Lütfen bunun sorunun genel bir cevabı olduğunu unutmayın. Kod örneği, yeni bir veritabanı bağlantısı açarak bir dış işlemle ilgili sorunu akıllıca çözer.

Performansla ilgili olarak: izolasyon seviyesine bağlı olarak, SEÇİM'ler değişen derecelerde KİLİTLER ve geçici veriler (anlık görüntüler) gerektirebilir. İşlem kapatıldığında bu temizlenir. Bunun COMMIT veya ROLLBACK ile yapılıp yapılmadığı önemli değildir. Harcanan CPU süresinde önemsiz bir fark olabilir - bir COMMIT'in ayrıştırılması muhtemelen bir ROLLBACK'ten (iki karakter daha az) ve diğer küçük farklardan daha hızlıdır. Açıkçası, bu yalnızca salt okunur işlemler için geçerlidir!

Kesinlikle istenmedi: Kodu okuyabilecek başka bir programcı, bir ROLLBACK'in bir hata durumu anlamına geldiğini varsayabilir.

Sadece bir ek not, ancak bu kodu şu şekilde de yazabilirsiniz:

using (IDbConnection connection = ConnectionFactory.CreateConnection())
using (IDbTransaction transaction = connection.BeginTransaction(IsolationLevel.ReadUncommitted))
using (IDbCommand command = connection.CreateCommand())
{
    command.Transaction = transaction;
    command.CommandText = "SELECT * FROM SomeTable";
    using (IDataReader reader = command.ExecuteReader())
    {
        // Do something useful
    }
    // To commit, or not to commit?
}

Ve işleri birazcık yeniden yapılandırırsanız, IDataReader için kullanım bloğunu da en üste taşıyabilirsiniz.

SQL'i bir saklı yordama koyarsanız ve bunu sorgunun üzerine eklerseniz:

set transaction isolation level read uncommitted

o zaman C # kodunda herhangi bir çemberden geçmek zorunda kalmazsınız. Bir saklı yordamda işlem yalıtım düzeyini ayarlamak, ayarın bu bağlantının gelecekteki tüm kullanımları için geçerli olmasına neden olmaz (bu, bağlantılar havuza alındığından diğer ayarlarla ilgili endişelenmeniz gereken bir şeydir). Depolanan yordamın sonunda, bağlantı ile başlatılan her şeye geri döner.

ROLLBACK çoğunlukla bir hata veya istisnai durumlarda kullanılır ve başarılı bir tamamlama durumunda COMMIT kullanılır.

İşlemleri COMMIT (başarı için) ve ROLLBACK (başarısızlık için) ile kapatmalıyız, önemsiz göründüğü salt okunur işlemlerde bile. Aslında tutarlılık ve geleceğe hazır olma açısından önemlidir.

Salt okunur bir işlem, mantıksal olarak pek çok şekilde "başarısız olabilir", örneğin:

• bir sorgu beklendiği gibi tam olarak bir satır döndürmüyor
• saklı yordam bir istisna yaratır
• alınan veriler tutarsız bulundu
• kullanıcı işlemi çok uzun sürdüğü için iptal ediyor
• kilitlenme veya zaman aşımı

COMMIT ve ROLLBACK salt okunur bir işlem için doğru şekilde kullanılırsa, örneğin önbelleğe alma, denetim veya istatistik gibi bir noktada DB yazma kodu eklenirse beklendiği gibi çalışmaya devam edecektir.

Örtülü ROLLBACK, yalnızca uygulama çöktüğünde veya kurtarılamaz bir hata, ağ arızası, elektrik kesintisi vb. İle çıktığında "ölümcül hata" durumları için kullanılmalıdır.

OKUMA'nın durumu değiştirmediği göz önüne alındığında, hiçbir şey yapmam. Bir commit yapmak, isteği veritabanına göndermek için bir döngü harcamak dışında hiçbir şey yapmaz. Durumu değiştiren bir işlem gerçekleştirmediniz. Aynı şekilde geri alma için.

Bununla birlikte, nesnelerinizi temizlediğinizden ve veritabanına olan bağlantılarınızı kapattığınızdan emin olmalısınız. Bu kod tekrar tekrar aranırsa bağlantılarınızı kapatmamak sorunlara yol açabilir.

AutoCommit'i false olarak ayarlarsanız, ardından YES.

JDBC (Postgresql sürücüsü) ile yapılan bir deneyde, sorgu sonlarını seçerseniz (zaman aşımı nedeniyle), geri almadıkça yeni seçme sorgusunu başlatamayacağınızı buldum.

Kod örneğinizde, sahip olduğunuz

1. // Kullanışlı bir şeyler yap

   Verileri değiştiren bir SQL İfadesi mi yürütüyorsunuz?

Değilse, "Oku" İşlemi diye bir şey yoktur ... Yalnızca Ekleme, Güncelleme ve Silme İfadelerinden (verileri değiştirebilen ifadeler) yapılan değişiklikler bir İşlemdedir ... Bahsettiğiniz şey, SQL'in kilitleridir. Sunucu, okuduğunuz verileri, bu verileri etkileyen DİĞER işlemler nedeniyle koyar. Bu kilitlerin seviyesi SQL Server İzolasyon Seviyesine bağlıdır.

Ancak SQL deyiminiz hiçbir şeyi değiştirmediyse, Commit veya ROll Back yapamazsınız.

Verileri değiştiriyorsanız, açıkça bir işleme başlatmadan izolasyon düzeyini değiştirebilirsiniz ... Her bir SQL İfadesi örtük olarak bir işlemdedir. Açıkça bir İşlem başlatmak, yalnızca 2 veya daha fazla ifadenin aynı işlem içinde olmasını sağlamak için gereklidir.

Tek yapmanız gereken işlem yalıtım düzeyini ayarlamaksa, bir komutun CommandText'ini "İşlem Yalıtım düzeyini Tekrarlanabilir Okuma" (veya istediğiniz herhangi bir düzeye) olarak ayarlayın, CommandType'ı CommandType.Text olarak ayarlayın ve komutu çalıştırın. (Command.ExecuteNonQuery () kullanabilirsiniz)

NOT: MULTIPLE okuma deyimi yapıyorsanız ve hepsinin veritabanının ilkiyle aynı durumunu "görmesini" istiyorsanız, yalıtım Düzeyini en üst Tekrarlanabilir Okuma veya Serileştirilebilir olarak ayarlamanız gerekir ...

Başkalarının aynı verileri okumasını engellemeniz mi gerekiyor? Neden bir işlem kullanmalı?

@Joel - Sorum şu şekilde daha iyi ifade edilebilir: "Okuma sorgusunda neden işlem kullanmalı?"

@Stefan - Depolanmış bir proc değil de AdHoc SQL kullanacaksanız, sorgudaki tablolardan sonra WITH (NOLOCK) ekleyin. Bu şekilde, bir işlem için uygulamada ve veritabanında ek yüke (minimum olsa da) maruz kalmazsınız.

SELECT * FROM SomeTable WITH (NOLOCK)

EDIT @ Yorum 3: Soru etiketlerinde "sqlserver" bulunduğundan, MSSQLServer'ın hedef ürün olduğunu varsaymıştım. Şimdi bu nokta açıklığa kavuştuğuna göre, belirli ürün referansını kaldırmak için etiketleri düzenledim.

İlk başta neden bir okuma işleminde işlem yapmak istediğinizden hala emin değilim.