J2ee Clustering Hgolle Wwwjavadilicom

m

1

i.c o

HACETTEPE ÜNİVERSİTESİ

BİLGİSAYAR MÜHENDİSLİĞİ BÖLÜMÜ BİL447 - YAZILIM MÜHENDİSLİĞİ LABORATUVARI ARAŞTIRMA ÖDEVİ

dil

(J2EE Clustering)

va

Hasan Gölle 20021905

ww w. ja

[email protected]

Ocak 2006, Hacettepe Üniversitesi Bilgisayar Mühendisliği

2

m

Önsöz ……………………………………………………………. 3 Temel terimler ………………………………………………….. 3 J2EE cluster mimarisi …………………………………………. 4

i.c o

J2EE clustering nedir? ………………………………………… 6 Web tier (dizi) clustering (öbekleme) gerçekleştirimi ………. 8

JBoss ile J2EE Clustering -Singleton Service ………………... 15 Uygulama sunucu dağıtımı ……………………………………. 16

ww w. ja

va

dil

Kaynaklar ……………………………………………………… 20

Ocak 2006, Hacettepe Üniversitesi Bilgisayar Mühendisliği

3

Önsöz

i.c o

m

Günümüzde çok fazla sayıda kritik görevli ve geniş çaplı uygulamalar Java 2, Enterprise Edition (J2EE) da çalıştırılmaktadır. Banka ve faturalandırma gibi kritik görevli uygulamalar üst düzeyde elde edilebilirlik gerektirirken Google ve Yahoo gibi geniş çaplı uygulamalar ise ölçeklenebilirlik gerektirirler. Elde edilebilirlik ve ölçeklenebilirliğin önemi şu olayla da ispatlanmıştır: Haziran 1999 da eBay’da 22 saatlik hizmet kesintisi 2.3 milyon müzayede kesintisine ve eBay’ın hisse değerinin yüzde 9.2 düşmesine neden olmuştur.

Temel Terimler

dil

Hata toleransı ile birlikte elde edilebilirlik ve ölçeklenebilirlik sağlama açısından J2EE clustering popüler bir teknolojidir. Fakat J2EE özelliğinin destek vermemesi nedeniyle J2EE satıcıları clustering’i farklı şekillerde gerçekleştirmişlerdir. Bu da J2EE mimarları ve geliştiricileri için sorunlara neden olmuştur.

Clustering altında yatan kavramları anlamak gereklidir. Bu kavramlardan bazıları; Ölçeklenebilirlik

ww w. ja

Yüksek elde edilebilirlik

va

Bazı geniş ölçekli sistemlerde son kullanıcıların sayısını ve davranışlarını önceden kestirmek zordur. Ölçeklenebilirlik, hızlı sayıda artan kullanıcıya destek verebilme yeteneğidir. Bunun sezgisel yolu kaynakları (hafıza, CPU, disk gibi) artırmaktır. Clustering ise alternatif bir yoldur. Bir grup sunucunun ağır işleri paylaşmasını ve tek bir mantıksal sunucu gibi davranmasını gerektirir.

Ölçeklenebilirliğe tek sunucu çözümü (kaynak artırma) tek hata noktası nedeniyle sağlıklı bir çözüm değildir. Kritik görevli uygulamalar (banka gibi) bir dakikalık bile kesintiye tolerans gösteremez. Bu hizmetlerin makul cevap verme süreleri olmalıdır. Clustering, bu tür elde edilebilirliğe yedek sunucular sağlayarak ve hata durumunda yedeğini çalıştırarak çözüm sağlar. Yük dengeleme

Clustering’in anahtar teknolojisidir. Gelen istekleri farklı sunuculara dağıtarak daha iyi performans sağlar. Yük dengeleyici basit bir servlet yada plug-in’den pahalı bir donanıma kadar pek çok şey olabilir. Hata Toleransı

Yüksek elde edilebilir veri çok doğru veri olmayabilir. J2EE cluster’da sunucu hata yaparsa kesilmez çünkü diğer istekler yedek sunucular tarafından değerlendirilir. Hata tolerans hizmetiyle az sayıda hataya rağmen doğru hizmeti garanti eder.

Ocak 2006, Hacettepe Üniversitesi Bilgisayar Mühendisliği

4 Failover

m

Hata toleransı sağlamak için gerekli diğer bir anahtar teknolojidir. Cluster’da başka bir düğüm seçmekle orijinal düğüm hata yapsa bile işlem devam eder. Başka bir düğüme failover açıkça kodlanabilir yada otomatikman yürütülür.

J2EE cluster şunları içerir: • Bir yada çok J2EE olgusu • Olgu yaratabilen merkezi servisler • Bir yada çok veritabanı

i.c o

J2EE Cluster Mimarisi

Minimum Cluster Yükleme

dil

Dağıtıcılar ve sunucular farklı fiziksel sunucular arasında dağıtılabilir. Merkezi hizmetler (mesaj hizmeti ve kuyruklama hizmeti) gereksinmeleri sağlayabilen bir host’a yüklenebilir.Genel olarak J2EE clustering teknolojisi “yük dengeleme” ve “failover” gerektirir.

ww w. ja

va

Aşağıdaki grafik SAP Web uygulamasının en basit cluster yüklemesini gösterir. Bu şekilde yüklenen sunucu yalnızca J2EE sorgularını işletir.

Ocak 2006, Hacettepe Üniversitesi Bilgisayar Mühendisliği

5 Bu J2EE cluster’da şunlar vardır: Dağıtıcı, üç sunucu ve yazılım yükleme yönecisi ile merkezi bir j2EE olgusu, Merkezi servisler, Veritabanı.

m

• • •

•

i.c o

J2EE olgusu şunları içerir: • 0-n J2EE dağıtıcı (genelde her olgu için bir dağıtıcı kullanılır ), Bir yada çok sunucu işlemi.

•

Geniş Cluster Yükleme

ww w. ja

va

dil

Aşağıdaki grafik daha büyük bir J2EE cluster yükleme gösterir. Dört olgu içerir, herbirinin olgu numarası vardır ve herbiri ayrı ayrı başlatılır, bitirilir ve gözlenebilir.

Ocak 2006, Hacettepe Üniversitesi Bilgisayar Mühendisliği

6

J2EE Clustering Nedir?

i.c o

m

Yük dengeleme

ww w. ja

va

Failover

dil

Şekilde görüldüğü gibi hedef nesnelerden eşzamanlı istekte bulunan birçok istemci nesne vardır. Çağıran ve çağrılan nesneler arasında bulunan yük dengeleyici, istekleri yedek nesnelere gönderir. Bu sayede yüksek performans sağlanır.

Şekilde görüldüğü gibi failover yük dengelemeden farklı çalışır. Bazen istemci nesne hedef nesneden ardışık metot istemlerinde bulunur. Eğer hedef nesne başarısız olursa failover sistemi bu hatayı bulmalı ve sonraki istemleri diğer nesneye yönlendirmelidir. Hata toleransı bu şekilde sağlanır.

Eğer J2EE clustering hakkında daha fazla öğrenmek istiyorsanız “ne tür nesneler öbeklenebilir” yada “J2EE kodda yük dengeleme ve failover nerede bulunmalı” gibi temel sorular sorabilmelisiniz. Aslında her nesne öbeklenemez ve J2EE kodda her yerde bulunamaz. Şu örnek koda bakalım;

Ocak 2006, Hacettepe Üniversitesi Bilgisayar Mühendisliği

dil

i.c o

m

7

va

Instance1 hata verirse Class A’nın business() metodu diğer B olgusu üzerine failover yada yük dengelemesi mi yapacak? Hayır. Yük dengelemesi ve failover için çağrılan ve çağıran arasında metot çağrılarını dağıtan ve farklı nesnelere yönlendiren bir yakalayıcı bulunmalıdır. Class A ve B nesneleri aynı JVM de çalışırlar ve sıkıca bağlıdırlar. Metot çağrıları arasına dağıtma mantığı eklemek zordur.

Öyleyse ne tür nesneler öbeklenebilir?- Yalnızca dağıtılmış topolojilere yüklenebilen bileşenler.

ww w. ja

Öyleyse J2EE kodda failover ve yük dengeleme nerde olur?- Yalnızca dağıtılmış nesnelerin metotlarının çağrıldığı yerlerde.

Ocak 2006, Hacettepe Üniversitesi Bilgisayar Mühendisliği

va

Şekil: Dağıtılmış nesneler

dil

i.c o

m

8

Şekildeki gibi dağıtılmış bir ortamda çağıran ve çağrılanlar belli sınırları olan farklı çalışma zamanı kaplarına ayrılırlar. Sınırlar JVM ile işlemler yada makineler arasında olabilir.

ww w. ja

Hedef nesne istemci tarafından çağrıldığında hedef nesnenin kabında işlev çalıştırılır. (Bu nedenle dağıtılmış denir). İstemciler ve hedef nesneler standart ağ protokolü ile haberleşirler. Bu özellikler sayesinde bazı mekanizmalar metot çağırma yoluna girerek yük dengeleme ve failover yürütebilir. Şekilde görüldüğü gibi tarayıcı uzak JSP nesnesini HTTP protokolü üstünden çağırabilir. JSP Web sunucu tarafından çalıştırılır, tarayıcı nasıl çalıştırıldığı ile ilgilenmez, yalnızca sonucu ister. Böyle bir senaryoda yük dengeleme ve failover işlevleri için tarayıcı ve web sunucu arasında bir şey bulunmalıdır. J2EE de dağıtma teknikleri JSP(Servlet), JDBC, EJB, JNDI, JMS, web servisleri ve diğerlerini içerir. Bu dağıtılmış metotlar çağrıldığında yük dengeleme ve failover yürütülür. Detaylı teknikleri bir sonraki bölümde anlatacağız.

Web tier (dizi) clustering (öbekleme) gerçekleştirimi Web dizisinde öbekleme J2EE clustering’de en önemli işlevdir. Web öbekleme teknikleri web yük dengeleme ve HTTP oturum failover içerir.

Ocak 2006, Hacettepe Üniversitesi Bilgisayar Mühendisliği

m

9

Web Yük Dengeleme

va

Şekil: Web yük dengeleyici

dil

i.c o

J2EE satıcıları web yük dengelemeyi birçok yöntemle başarırlar. Temelde yük dengeleyici tarayıcılar ile web sunucuları arasına girerler.

ww w. ja

Yük dengeleyici F5 yük dengeleyici gibi donanımsal bir ürün olabilir, ve yük dengeleyici plug-in’leri ile birlikte bir web sunucu da olabilir. Ip zincirleri ile bir Linux kutusu yük dengelemeyi yapabilir. Hangi tekniği kullanırsa kullansın yük dengeleyici şu özelliklere sahiptir; . Yük dengeleme algoritmalarını gerçekleştirir İstemciden istek geldiğinde yük dengeleyici bu istekleri en son sunucu olgularına nasıl dağıtacağına karar verir. Popüler algoritmalar round-robin, random ve ağırlık tabanlı olanlardır. Yük dengeleyici her sunucu olgusuna eşit iş yükünü sağlamaya çalışır, fakat yukarıdaki algoritmalardan hiçbiri mükemmel eşitliği sağlayamaz çünkü hepsi bir sunucu olgusuna dağıtılan istekleri temel alırlar. . Sağlık kontrolü

Bazı sunucu olguları hata verirse yük dengeleyici bu hatayı bulmalı ve o sunucuya bir daha istek göndermemelidir. Yük dengeleyici ayrıca bu sunucu geri döndüğünde izlemeli ve istek göndermeye devam etmelidir.

Ocak 2006, Hacettepe Üniversitesi Bilgisayar Mühendisliği

10 . Oturum

i.c o

m

Hemen hemen her web uygulaması oturum durumlarına sahiptir, bunlar log-in durumu yada alışveriş listesini hatırlamak kadar basit olabilir. Http protokolü durumsuz olduğundan oturum durumu bir yere kaydedilmeli ve aynı uygulamadan tekrar istendiğinde geri çağrılabilmelidir. Yük dengeleyici için bazı tarayıcı oturumlarının isteklerini en son dağıtılan sunucu olgusuna dağıtmak en iyi çözümdür.

Oturum durumu web sunucu olgusunun hafızasına yüklendiğinden yük dengeleme için oturum özellikleri önemlidir. Eğer bir sunucu olgusu güç kesilmesi gibi bir nedenle hata verirse bu sunucudaki oturum durumu kaybedilir. Yük dengeleyici bu hatayı bulmalı ve o sunucuya bir daha istek göndermemelidir. Fakat oturum durumu hata veren sunucuda kayıtlı olan istekler bütün oturum bilgilerini yitirirler ve bu da hataya neden olur. Bu durumda oturum failover ortaya çıkar.

ww w. ja

va

dil

HTTPOturum (HTTPSession) Failover

Şekil: HTTPOturum Failover

Bütün popüler J2EE satıcıları bütün istemci isteklerinin oturum durumu yitirilmeden işletildiğinden emin olmak için kendi cluster ürünlerinde HTTPOturum failover gerçekleştirirler. Üstteki şekilde görüldüğü gibi tarayıcı, durumlu bir web uygulamasını ziyaret ettiğinde (1,2. adımlar) bu uygulama daha sonra kullanmak için hafızada oturum nesnesi oluşturabilir. Aynı zamanda tarayıcıya bu oturum nesnesini belirleyecek HTTPOturum kimliği gönderir(3. adım). Tarayıcı bu kimliği “cookie” (çerez) olarak kaydeder ve aynı web sunucudan sayfa istediğinde yeniden gönderir. Oturum failover desteklemek için web sunucudaki oturum nesnesi kendini yedeklemelidir(adım 4), böylece sunucu hatalarında oturum kaybı önlenir. Yük dengeleyici hatayı fark ettiğinde (5, 6. adım) sıradaki istemleri aynı uygulama içindeki diğer sunucu olgusuna gönderir. Oturum durumu bir yerde yedekli olduğundan bu yeni web sunucu olgusu oturumu geri getirir(adım 8) ve istemleri yürütür.

Ocak 2006, Hacettepe Üniversitesi Bilgisayar Mühendisliği

11 HTTPOturum failover gerçekleştiriminde şu kavramlar dikkate alınmalıdır.

m

. Global HTTPOturum Kimliği(ID)

. Oturum durumları nasıl yedeklenir

i.c o

Yukarda belirtildiği gibi HTTPSession kimliği hafıza içi oturum nesnesini belirlemede kullanılır. J2EE de HTTPOturum kimliği JVM olgusuna bağlıdır. Her JVM olgusu birden çok web uygulamasını tutabilir, her bir uygulama farklı kullanıcılar için birçok HTTPOturum tutabilir. HTTPOturum kimliği o anki JVM olgusunda ilgili oturum nesnesine erişmek için anahtar rolündedir. Farklı JVM olguları iki tane aynı HTTPOturum kimliği üretmemelidir, çünkü failover olduğunda bir JVM deki oturumlar yedeklenebilir ve diğerinden çağrılabilir. Sonuç olarak global HTTPOturum kimliği mekanizması gerçekleştirilmelidir.

. Yedekleme sıklığı

dil

Oturum durumlarının nasıl yedeklendiği konusu J2EE sunucuyu özel yapmak ve diğerlerinden üstün kılmak için anahtar rolündedir. Farklı satıcılar farklı şekilde gerçekleştirmektedir.

va

HTTPOturum durum yedeklemenin performans maliyetleri vardır(CPU devri, ağ bant genişliği, veritabanına yada diske yazma IO maliyeti gibi). Yedekleme sıklığı cluster performansını önemli ölçüde etkiler.

Veritabanı devamlılığı yaklaşımı

ww w. ja

Bütün popüler J2EE cluster ürünleri oturum durumunuzu yedeklemeniz için size JDBC arayüzü üstünden ilişkisel veritabanı seçme olanağı sunar.Alttaki şekilde görüldüğü gibi bu yaklaşım basitçe sunucu olgusunun oturum içeriğini serileştirmesi ve veritabanına yazmasıdır. Failover olduğunda diğer bir sunucu olgusu hatalı sunucunun sorumluluğunu alır ve veritabanından bütün oturum durumlarını geri alır. Nesnelerin serileştirilmesi önemlidir çünkü bu sayede hafıza içi verinin kalıcı ve taşınabilir olması sağlanır. Java nesne serileştirimi için http://java.sun.com/j2se/1.5.0/docs/guide/serialization/index.html” adresine bakınız.

Oturum durumunu veritabanına yedekleme

Veritabanı sorguları maliyetli olduğundan bu yaklaşımın temel dezavantajı oturumlar içinde çok sayıda nesne saklandığında sınırlı ölçeklenebilir olmasıdır. Veritabanı oturumu kullanan çoğu uygulama sunucuları nesneleri saklamak için minimum HTTPOturumu kullanmayı savunur, fakat bu web uygulamasının mimarisini ve tasarımını kısıtlar. Buna rağmen veritabanı yaklaşımının bazı avantajları da vardır. • • •

Gerçekleştirimi kolaydır. Veritabanı paylaşımlı olduğundan oturum başka bir host’a failover edebilir. Oturum bilgisi tüm öbek çökene kadar durur.

Ocak 2006, Hacettepe Üniversitesi Bilgisayar Mühendisliği

12

m

Hafıza kopyalama yaklaşımı

dil

i.c o

Performans nedenlerinden ötürü bazı J2EE sunucu’ları (Tomcat, JBoss, Weblogic, and Websphere) alternatif bir yaklaşım getirmiştir: Hafıza kopyalama

va

Şekil: Oturum durumu için hafıza kopyalama

ww w. ja

Hafıza tabanlı oturum, oturum bilgilerini veritabanı yerine bir yada birkaç yedek sunucuda tutar. Bu yaklaşım yüksek performansı nedeniyle çok popülerdir. Veritabanı yaklaşımına kıyasla orijinal sunucu ile yedek sunucular arası ağ haberleşmesi çok önemsiz kalır. Ayrıca veritabanı yaklaşımındaki geri okuma aşamasına gerek kalmaz çünkü zaten oturum bilgisi yedek sunucuda bulunmaktadır. “JavaGroups” JBoss ile Tomcat öbekleme arasındaki haberleşme katmanıdır. “Grup üyeliği protokolleri” ve “mesaj yayını” gibi öbekleme için temel özellikleri sağlar. Daha fazla bilgi için “http://www.jgroups.org/javagroupsnew/docs/index.html”. adresine bakınız.

Tomcat’in yaklaşımı: Çoklu-sunucu kopyalama Hafıza kopyalamanın birçok değişik yöntemi vardır. İlki oturum bilgisini cluster’daki bütün düğümlerde kopyalamaktır. Tomcat 5 bunu şu şekilde yapar.

Ocak 2006, Hacettepe Üniversitesi Bilgisayar Mühendisliği

Şekil: Çoklu-sunucu kopyalama

dil

i.c o

m

13

va

Şekilde görüldüğü gibi bir sunucu olgusunda oturum değişirse o sunucu verilerini bütün diğer sunuculara yedekler. Bir sunucu olgusu hata verirse yük dengeleyici yedek olarak diğer sunucuyu seçebilir. Fakat bu yaklaşımın ölçeklenebilirlik açısından kısıtları vardır. Eğer öbekte çok sayıda olgu varsa ağ haberleşmesi maliyeti gözardı edilemez.

Weblogic, Jboss ve WebSphere yaklaşımı- eşli sunucu kopyalama

ww w. ja

Performance ve ölçeklenebilirlik açısından Weblogic, JBoss ve Websphere başka bir hafıza kopyalama geliştirmiştir: Her sunucu olgusu oturum bilgisini tutmak için keyfi bir yedek olgu seçer.

Ocak 2006, Hacettepe Üniversitesi Bilgisayar Mühendisliği

14

m

. Bu yolla her sunucu olgusu kendi eş yedek sunucusuna sahiptir Bu yaklaşım ölçeklenebilirlik problemine çözüm getirir, fakat şu kısıtları vardır: . Yük dengeleyiciye karmaşıklık getirir. Bir sunucu olgusu hata verirse yük dengeleyicinin hata veren sunucunun eşini bilmesi gerekir. Bu da yük dengeleyicinin alanını kısıtlar.

i.c o

. Normal istem gerçekleştirme haricinde sunucular kopyalama sorumluluğunu da almalıdır. . Normal işlem esnasında yedek oturumları tutmak için kullanılan hafıza, failover olmazsa yedek sunucularda boşa harcanır.

IBM’in yaklaşımı- merkezi durum sunucu

ww w. ja

va

dil

Websphere’de hafıza kopyalamaya alternatif bir çözüm vardır: Merkezi durum sunucuya yedek durum bilgisi.

Şekil: Merkezi sunucu kopyalama

Veri tabanı çözümüne çok benzerdir. Veritabanı sunucu yerine “oturum yedek sunucu” kullanılmıştır. Bu yaklaşım şu avantajları getirir: . Yürütülen işlemleri yedek oturum işlemlerinden ayırmak cluster’ı daha sağlam yapar. . Bütün oturum bilgileri ilgili sunucuda yedeklenmiştir. Hafıza tüketen sunucu olgularına gerek yoktur.

. Uygulama sunucu ile oturum yedek sunucu arasındaki soket haberleşmesi veritabanı bağlantılarına göre basit olduğundan daha iyi performans verir. Buna rağmen “geri okuma” aşaması nedeniyle performansı hafızanın eşler arasında direk kopyalandığı çözüm gibi olamaz. Ayrıca fazladan oturum yedek sunucuları karmaşa getirir.

Ocak 2006, Hacettepe Üniversitesi Bilgisayar Mühendisliği

15

dil

i.c o

m

Sun’ın yaklaşımı- Özel veritabanı

va

Sun JES uygulama sunucusu oturum failover’a farklı bir yaklaşım getirir. Veritabanı yaklaşımına benzese de aslında JES’in kullandığı veritabanı (HADB) oturum erişimi için optimize edilmiştir ve bütün veriyi hafızada tutar. Dolayısıyla merkezi durum sunucu yaklaşımına daha yakındır.

JBoss ile J2EE Clustering -Singleton Service

ww w. ja

Singleton hizmet veren cluster içindeki düğüme efendi düğüm denir. Efendi düğüm hata verirse diğerleri arasından bir efendi seçilir ve servis tekrar başlar.

Ocak 2006, Hacettepe Üniversitesi Bilgisayar Mühendisliği

ww w. ja

va

dil

i.c o

m

16

Uygulama sunucu dağıtımı

Cluster’ınıza uygulama sunucu olgularını dağıtırken cluster’da tek düğümde birden çok uygulama sunucu olgusu istediğinize karar vermelisiniz, ve cluster’daki toplam düğüm sayısını belirlemelisiniz.

Bir düğümdeki uygulama sunucu sayısı CPU sayısına, kullanımına ve hafızaya bağlıdır. Cluster’daki optimum düğüm sayısını belirlemek tekrarlı bir iştir. Öncelikle uygulamanın profili çıkarılır ve optimize edilir. Sonra maksimum kullanım için yük testi yapılır. Son olarak hata olduğunda yükü kaldıracak fazladan düğümler eklenir.

Ocak 2006, Hacettepe Üniversitesi Bilgisayar Mühendisliği

17

m

Oturum depolama anahatları Kırılmayı minimize etmek için uygulama sunucu’ları anahatları takip edilmelidir:

i.c o

Bütün nesneler ve HttpOturumda özyineli olanlar serileştirilebilir olmalıdır ve java.io.Serializable gerçekleştirmelidir.

HttpOturumda nesnenin durumu değiştiğinde nesnenin değiştiğini belirtmek ve değişikliği yedek sunucuya kaydetmek için session.setAttribute(...)çağrılır. AccountModel am = (AccountModel)session.getAttribute("account"); am.setCreditCard(cc);

dil

//You need this so the AccountModel object on the backup receives the //Credit card session.setAttribute("account",am); ServletContext serializable değildir bu nedenle olgu değişkeni olarak kullanılamaz.

va

EJB uzak nesneleri serileştirilemezler. Serileştirilemeyen durumlarda mekanizma aşağıdaki ile değiştirilir (Bu sınıf java.io.Serializable gerçekleştirilmez çünkü superclass’ı AccountModel bunu yapar).

...

ww w. ja

public class AccountWebImpl extends AccountModel implements ModelUpdateListener, HttpSessionBindingListener { transient private Account acctEjb; ...

private void writeObject(ObjectOutputStream s) { try {

s.defaultWriteObject(); Handle acctHandle = acctEjb.getHandle(); s.writeObject(acctHandle); } catch (IOException ioe) { Debug.print(ioe); throw new GeneralFailureException(ioe); } catch (RemoteException re) { throw new GeneralFailureException(re); }

}

Ocak 2006, Hacettepe Üniversitesi Bilgisayar Mühendisliği

18

m

private void readObject(ObjectInputStream s) { try { s.defaultReadObject(); Handle acctHandle = (Handle)s.readObject() Object ref = acctHandle.getEJBObject(); acctEjb = (Account) PortableRemoteObject.narrow(ref,Account.class);

dil

i.c o

} catch (ClassNotFoundException cnfe) { throw new GeneralFailureException(cnfe); } catch (RemoteException re) { throw new GeneralFailureException(re); } catch (IOException ioe) { Debug.print(ioe); throw new GeneralFailureException(ioe); } }

va

Oturum diskten geri yazıldığında ve HttpSession's setAttribute(...) methodu her çağrıldığında HttpSessionBindingListener' ın valueBound(HttpSessionBindingEvent event) methodu çağrılır. Buna rağmen failover esnasında valueBound(HttpSessionBindingEvent event) çağrılmaz.

Hafıza içi oturum durum kopyalaması

ww w. ja

Hafıza içi oturum durum kopyalaması veritabanı yaklaşımından daha zordur çünkü HttpOturum’daki her bir nesne değiştikçe yedek sunucuda serileştirilebilir. Veritabanı yaklaşımı durumundaysa oturumdaki nesnelerin biri değişse hepsi birden serileştirilir. Hata durumunda uygulama çalışır fakat bazı özellikler çalışmayabilir- alışveriş kartı daha fazla parçayı reddedebilir örneğin. Problem, uygulamanızın aynı alışveriş kart nesnesine referans gösteren farklı parçalarından (alışveriş kartını güncelleyen ve gösteren) kaynaklanır. Tek sunucu durumunda bu durum görülmez çünkü her parça aynı nesneye referans gösterir. Aşağıda dolaylı kopyalayan nesnelerin örneği görülmektedir.

import java.io.*; public class Aaa implements Serializable { String name;

pubic void setName (String name) { this.name = name; } public String getName( ) { return name; }

}

Ocak 2006, Hacettepe Üniversitesi Bilgisayar Mühendisliği

19

m

import java.io.*; public class Bbb implements Serializable {

public Bbb (Aaa a) { this.a = a; }

i.c o

Aaa a;

pubic void setName (String name) { a.setName(name); }

public String getName( ) { return a.getName(); }

In first.jsp on sunucu1:

va

<% Aaa a = new Aaa(); a.setName("Abe"); Bbb b = new Bbb(a);

dil

}

// a is copied to backup machine under key "a" session.setAttribute("a",a);

ww w. ja

// b is copied to backup machine under key "b" session.setAttribute("b",b); %> In second.jsp on sunucu1:

<% Bbb b = (Bbb)session.getAttribute("b"); b.setName("Bob"); // b is copied to backup machine under key "b" // but object Aaa under key "a" has the name "Abe" // and "b"'s Aaa has the name "Bob" session.setAttribute("b",b); ---> Failure trying to get to sunucu1's third.jsp ----->Failover to sunucu2's (backup machine) third.jsp In third.jsp on sunucu2:

The name associated with Object Aaa is: <%=((Aaa)session.getAttribute("a")).getName()%> The name associated with Object Aaa through Object Bbb is:

Ocak 2006, Hacettepe Üniversitesi Bilgisayar Mühendisliği

20

m

<%=((Bbb)session.getAttribute("b")).getName()%> ... //End of third.jsp

i.c o

İlk ifade etiketi “Abe” çıktısı verirken, ikincisi “Bob” üretir. Tek sunucu durumunda her ikisi de “Bob” üretir.

Kaynaklar:

ww w. ja

va

dil

http://www.theserverside.com/articles/article.tss?l=J2EEClustering http://www.javaworld.com/javaworld/jw-08-2001/jw-0803-extremescale2.html http://help.sap.com/saphelp_webas630/helpdata/en/2e/611724f410254ca12a3f396ec5ae85/content.htm http://www.onjava.com/pub/a/onjava/2003/08/20/jboss_clustering.html

Ocak 2006, Hacettepe Üniversitesi Bilgisayar Mühendisliği