Biraz düşündüm; oturum (session) yöneticisi, başlı başına bir veritabanı yöneticisi gibi...:)
Öyle ki, geçici dosyaların düzenli bakım yapılabilmesi için parameter/logs verilerinin bir dosyada tutulması gerekiyormuş. Zaten oturum kimliği (sId) istemci tarafından ve sayfalar arası geçiş yapılıyorken ya HTML içine, ya da 'post method'u olarak geçirilecek. Eğer bu kimliğin süresi dolmadıysa ve karşılığı sunucuda bulunuyorsa (hacking, injection) istemciye veri gönderilir.
Buraya kadar sorun yok, her şey net...
Amaaa, RhS bir yorumlayıcı olduğuna göre; istemci her defa veri talep ettiğinde, belli kurallar (güvenlik önlemleri) çerçevesinde veri tabanı ile yeniden bağlantı kurulacak. Veritabanlarının bu tür işlemlere (reconnection) verdiği tepkileri (performance) bilemiyorum ama Adobe Flash'ın depolama alanını kullanma becerisine göre yavaş kalacağını zannediyorum.
Düşünsenize!
Binlerce istemci bir web sitesine giriyor, kimi ziyaretten kısa bir süre sonra ayrılırken kimi (örneğin bir e-ticaret sitesi alışveriş yapmaya) devam ediyor. Her ne kadar tarayıcı (browser) kapatılmasa bile, oturum süresi boyunca veritabanına defalarca bağlanma gerçekleşebilir. Vuuuuvv....:)
Peki, hiç veritabanı ile uğraşmasak ve zaten hali hazırda çağrılması gerekecek std.file sınıfı (OS File Systems) ve JSON yapısı bize, anahtar teslim (tüm ihtiyaç duyulan çözümleri ile) veritabanı sunucusu veremez mi?
Neler olabilir:
- 1. sId, istemciye atandığında tarih/saat bilgisi ile bir MD5 (veya başka bir algoritmanın) kodu oluşturulur...
- 2. Bu kod ile aynı ismi taşıyan verilerin yazılacağı dizin meydana getirilir,
- 3. Tam o sırada gerekiyorsa (maintenanceTime < realTime ise) bakım yapılır:
** Eğer bakım zamanı (maxTimeOut*latencyTime + lastSessionTime) geldiyse ve başka bakım yapan (maintenanceLock) yoksa geçmişteki dosyalar artık kesinlikle çöp dosyalardır. Bu sırada başka istemci temizlik yapma ihtimaline karşı maintenanceLock çok önemlidir!
** İşte burada başka bir alt başlık çıkıyor; o da yorumlayıcı için bazı sabit ve değişkenlerin tutulduğu 'configuration file'. Aslında günlük tutma (log file) da gerekebilir. Örneğin yorumluyucu kaç defa doğru bir şekilde çalıştırıldı veya bunların kaçı hata iletisi gönderdi gibi. Öyleyse, bir taşla bir kaç kuş vurarak pekala geçici değişkenleri yine aynı sistem ile (JSON) ama geçerlilik süresi sonsuz olacak şekilde tutabiliriz.
- 4. İstemcinin talep ettiği veriler, web sitesinin ana veritabanından süzülür:
** Bu veriler, gezilen sayfanın (pId) içeriği olabileceği gibi önceki bir sayfada kullanıcı dosyaları (örneğin doldurduğu bir form) da olabilir. Bu durumda, oturum kimliği (sId) ile oluşturulan dizin, aslında geçerlilik süresi (sTimeOut) boyunca ihtiyaç duyulabilecek tüm verilerin tutulduğu yerdir. Bence pId sayfası yeniden çağrıldığında büyük (hacimli olan) ana veritabanından tekrar veri talep edilmez. Zaten o daha önce sId ile oluşturulan dizin içindeki dosyalardadır. Bu dosyaların isimleri veritabanındaki düğümün veya çizelgenin (table) ismi olabilir.
Evettt, sanırım bir taşla 2, 3 hatta 4 kuş (caching) vurmuş oluyoruz...:)
- 5. Süzülen veri vakit geçirilmeden (hazır hafızadayken) istemciye gönderilir ve bir kopyası kayıt edilir. Belki koşut işlem (parallel processing) yaparak aynı anda bu işlem yapılabilir.
--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]
Permalink
Reply