From: Nilgün Belma Bugüner (nilgun@superonline.com)
Date: Thu 06 Jun 2002 - 18:53:39 EEST
¦[
¦[ Veri aktarım örneğini verdim, ama bir transaction için aslında
¦[ emir/eylem/emirin yapıldığı teyidi söz konusu. Bu emir "falanca veriyi
¦[ al ve kaydet" olabileceği gibi başka şeyler de olabilir. İşin içine
¦[ veriyi ilgilendirmeyen transaction girince hepten olay çığrından çıkıyor
¦[ diye düşünüyorum. Örneğin bir transaction "daemonları yeniden başlat"
¦[ olabilir. Bu transaction'un atomik olması (ya hep, ya hiç) zor. Fakat
¦[ transaction olması için sıralanabilmesi, o transaction yapılırken bir
¦[ başka transaction'unun yapılmamasının sağlanması, ve transaction yapıldı
¦[ diye geri bilgi beslemesi yeterli.
¦[
Bütün transaction'lar geriye bilgi döndürmez. Veritabanı ile eşzamanlı çalışırsanız
bu işlem gerçekleşir. Bir tr. tamamlanmadan yenisine geçilmez. Ancak bu işlem
veritabanının verimliliğini düşürdüğünden, işlemin bitmesi beklenmez, yazılım
sizden bilgiyi alır ama size bilgi dönmez. Yazılım onu bir ara işler. Zaten veritabanı
yazılımlarında zorluk burada başlar, bir işlem diğerinin yaptığının tersini gerçekleştirebilir.
Bunu önleyici önlemler işi zorlaştırır. Ama ister eşzamanlı çalışılsın ister eşzamanlamasız
işlem transaction'dır. Transaction'ların sıralı işlenmesi şart değildir, thread'lerle,
çok sayıda sanal sunucu oluşturarak (havuzlama) aynı veritabanı üzerinde çok sayıda
işlem gerçekleştirmek mümkündür, çok yoğun işlem yapılan sunucularda kimin önce geldiğininde
pek önemi kalmaz, bu noktada devreye havuz girer aynı kayıt için sıraya sokar. Yoksa eninde
sonunda hangi sanal sunucunun veritabanını ne kadar önce sorguladığına bağlıdır işlem sırası.
İşlem biraz multicasting'i andırır. Çoğa gönderim olmadığından sadece andırır.
Bu bakımdan iş bitti teyidi olması ile bu terimi sınırlamak yanlıştır.
İşlem basitçe veri aktarımıdır. Bu örnekte aktarımın hedefi veritabanıdır.
Esen kalın,
Nilgün