| Dragi Tata |
18. 09. 2006. 18:56 |
Lamp i distribuirane Web aplikacije
Out of curiosity: kakva je podrška LAMP tehnologija za distribuirane web aplikacije. Recimo, koji se middleware koristi, kakva je podrška za transakcije, itd.
Konkretno, koje bi LAMP tehnologije koristili za ovako nešto (primer J2EE:) http://www.tusc.com.au/tutorial/html/chap2.html |
| Ilija Studen |
18. 09. 2006. 20:13 |
Kad je PHP u pitanju nema potrebe za enterprise terminologijom, dijagramima i sličnim stvarčicama. PHP scaleuje po defaultu. Resursi između izvršavanja se ne dele već se uništavaju čim se akcija izvrši. Zahvaljujući tome PHP aplikaciju možeš da širiš horizontalno na praktično neograničen broj mašina - svaki zahtev je država za sebe, ma gde da se izvršavao.
Scenario je prost: imaš server baze (koji je opet država za sebe i može da se izvršava na više mašina, sa tim PHP nema veze) i imaš niz "aplikacionih" servera koji voze jednu te istu PHP skriptu i nalaze se iza load balancera koji ravnomerno prosleđuje zahteve. To je to.
Uglavnom, kad je reč o PHP-u treba da se potrudiš pa da napraviš aplikaciju koja NE scaleuje ;) Baš sam danas slušao intervju sa Rasmus Lerdorfom (autor PHP-a). Zanimljivo zapažanje: ljudi tvrde da PHP ne scaleuje jer nema mnogo tekstova o toj temi online. Razlog zašto nema mnogo tekstova je zato što to kod PHP-a i nije problem. Cela priča se može ispričati u 5 rečenica.
Način na koji PHP radi je ponekad ograničavajuć jer moraš da koristiš nešto da bi očuvao stanje između zahteva. Koliko je to mana toliko je i prednost. Na celu stvar gledaš iz ugla problema koji rešavaš.
Btw, tako stvari funkcionišu po rečima onih koji su pravili slična rešenja (ja nisam). Kada stvarno napravim nešto što će zahtevati ovakvu arhitekturu (nadam se uskoro) moći ću da podelim i neke konkretnije detalje.
|
| marinowski |
18. 09. 2006. 21:03 |
Pomenuo sam vec ranije prezentaciju Cala Handersona o funkcionisanju Flickra:
http://www.niallkennedy.com/blog/uploads/flickr_php.pdf
Po meni je to pravi primer poznavanja tehnologije. Ne radi se tu o nekom ekstremnom menjanju postojece infrastrukture, nego o poznavanju prednosti i mana istih. Toplo preporucujem ovu prezentaciju.
Najlakse je uzeti neko gotovo resenje, a kada se servis optereti, samo redjas servere i pricas okolo: znas, nase je resenje skalabilno ... pfff.... |
| Dragi Tata |
18. 09. 2006. 22:14 |
Citat:
Originalno napisao Ilija Studen
Scenario je prost: imaš server baze (koji je opet država za sebe i može da se izvršava na više mašina, sa tim PHP nema veze) i imaš niz "aplikacionih" servera koji voze jednu te istu PHP skriptu i nalaze se iza load balancera koji ravnomerno prosleđuje zahteve. To je to.
|
Kako se npr. rešavaju slučajevi heterogenih transakcija? Npr, moraš da u toku jedne transakcije promeniš rekorde u 3 sasvim različite baze. |
Off Topic: E bilo bi super kad bi neko napisao vrste aplikacija. distribuirane (?), cisto radi edukacija nas dizajnera. |
| dedamunila |
18. 09. 2006. 22:25 |
Citat:
Originalno napisao Dragi Tata
Out of curiosity: kakva je podrška LAMP tehnologija za distribuirane web aplikacije. Recimo, koji se middleware koristi, kakva je podrška za transakcije, itd.
|
+1. To i mene veoma zanima, kao nekoga ko razmatra prelazak (ili delimicni prelazak) sa MS-a na neku otvorenu platformu. Onoliko koliko sam do sada mogao da vidim, ta podrska (za middleware) na LAMP-u je 0. Znam, middleware se ne koristi svaki dan (npr. ja se ni ne secam vise kada sam zadnji put otvorio COM+ konzolu na Windowsu), ali... Cini mi se da je Java tu zakon (pogotovo sa gomilom open source application servera), ali nekako nije popularna na Webu, ne znam za mnogo high-traffic sajtova na Javi. Imam utisak da od nje beze kao da je sugava, a ne znam zasto i to me jako nervira.
Citat:
Originalno napisao Ilija Studen
Kad je PHP u pitanju nema potrebe za enterprise terminologijom, dijagramima i sličnim stvarčicama. PHP scaleuje po defaultu.
|
Ilija, ovo ne drzi vodu. Nije skalabilnost jedino cemu middleware sluzi (tu su jos, recimo, distribuirane transakcije, reliable messaging kojim se cesto ostvaruje async komunikacija itd.). Stateless, shared nothing arhitektura gde se sve cuva u bazi, moze se koristiti na svakoj platformi. Poenta je u tome da to ponekada usporava sistem, gotovo uvek cini programiranje tezim i sl. Npr. ASP.NET ima mogucnost cuvanja session state-a na vise mesta, od kojih je jedno SQL Server baza. Ta opcija je npr. ubedljivo najsporija.
Jos jedna stvar jako zanima: kako se na LAMPu pravi daemon/service aplikacija (npr. kada treba pokrenuti neku obradu kada stigne mail ili SMS poruka)? Citajuci gore pomenuti tekst o Flickr-u (gde pise da su to oni uradili pomocu Jave) stekao sam utisak da to ni ne moze. Da li gresim? |
| skaarj |
18. 09. 2006. 22:39 |
@[ng]
Distribuirane web aplikacije oznacavaju (najprostije receno) sisteme koji se rasprostiru na vise servera. Opste je poznato da vise servera manje snage u najvecem broju slucajeva daju bolje rezultate nego jedan server velike snage. To je sve ok dok se aplikacija ne zakomplikuje pa treba cuvati stanje izmedju dva zahteva koji su upuceni fizicki razlicitim masinama. Recimo da se desi da izmedju dva zahteva jedan od servera crkne i tvoj drugi zahtev se automatski prosledjuje na drugi dostupan server... Uvidjas problem?
O temi se moze jako puno pricati i ima raznih zanimljivih problema koji se tu desavaju ali globalno mali broj sajtova zahteva preterano komplikovanje oko toga.
JEE je zamisljen da resi problem u tim najkomplikovanijim mogucim slucajevima dok PHP i nije. Naravno, to niposto ne znaci da JEE ne moze da resi jednostavne probleme ni da PHP ne moze da resi jako kompleksne.
|
| Dragi Tata |
18. 09. 2006. 22:47 |
|
| dedamunila |
18. 09. 2006. 22:47 |
Citat:
Originalno napisao [nq]
Off Topic: E bilo bi super kad bi neko napisao vrste aplikacija. distribuirane (?), cisto radi edukacija nas dizajnera.
|
Distribuirane aplikacije su ti kao funkcionalne Flash prezentacije - o njima se prepricavaju legende, ali niko nije uspeo da dokaze njihovo postojanje :1064:
Distribuirane su ti one aplikacije koje se izvrsavaju na vise masina (neki vole da kazu "ciji se delovi izvrsavaju na vise masina"). To izvrsavanje na vise masina donosi neke lepe stvari (bolje performanse, otpornost na otkaze itd.), ali i probleme (koji se uglavnom svode na probleme sinhronizacije rada tih masina, pojednostavljeno govoreci). |
| dinke |
18. 09. 2006. 22:57 |
Citat:
Originalno napisao dedamunila
Jos jedna stvar jako zanima: kako se na LAMPu pravi daemon/service aplikacija (npr. kada treba pokrenuti neku obradu kada stigne mail ili SMS poruka)? Citajuci gore pomenuti tekst o Flickr-u (gde pise da su to oni uradili pomocu Jave) stekao sam utisak da to ni ne moze. Da li gresim?
|
Nisam citao pomenuti tekst, ali veruj mi da PHP moze da radi u cli-u i samim moze da radi i kao deamon. Moze se napraviti socket server, moze da radi kao SOAP server i sl. Nisam se bakcao sa SMS porukama, ali za e-mail se bez problema koristi .qmail-emailaccount fajl koji forkuje php fajl koji moze da pokupi attachment i sl iz emaila. Radio to pre par godina i funkcionise (u nedostatku bolje reci) - savrseno :)
Inace, nisam uopste upucen u .NET i distribuirane aplikacije (od ovih J2EE linkova sto je DT postavio mi se dize kosa na glavi od terminologije ;) ali bas ovih dana radim na jednoj ajd da kazem "distribuiranoj aplikaciji", gde imam na nekoliko servera PHP CLI scriptove (klijente) koji obradjuju milione keyworda, a na glavnom serveru cuvam rezultate procesiranja u jednoj MySQL bazi. U tabeli se cuvaju hostovi tih klijenata, pa se keywordi rasporedjuju na onoliko masina koliko ih ima u procesu. Ne pretereno inteligentno, ali moze se skalirati sa dodavanje novih servera i sl.
E sad, ista stvar bi mogla i preko SOAP-a recimo, gde je na glavnoj masini SOAP server prima zahteve od ovih SOAP klijenata, ali obzirom da nemam PHP5 na tom serveru, nisam zeleo da se bakcem sa starim (PEAR SOAP ili NUSoap) bilbiotekama. |
| dedamunila |
18. 09. 2006. 23:02 |
Citat:
Originalno napisao dinke
Nisam citao pomenuti tekst, ali veruj mi da PHP moze da radi u cli-u i samim moze da radi i kao deamon. Moze se napraviti socket server, moze da radi kao SOAP server i sl. Nisam se bakcao sa SMS porukama, ali za e-mail se bez problema koristi .qmail-emailaccount fajl koji forkuje php fajl koji moze da pokupi attachment i sl iz emaila. Radio to pre par godina i funkcionise (u nedostatku bolje reci) - savrseno :)
Inace, nisam uopste upucen u .NET i distribuirane aplikacije (od ovih J2EE linkova sto je DT postavio mi se dize kosa na glavi od terminologije ;) ali bas ovih dana radim na jednoj ajd da kazem "distribuiranoj aplikaciji", gde imam na nekoliko servera PHP CLI scriptove (klijente) koji obradjuju milione keyworda, a na glavnom serveru cuvam rezultate procesiranja u jednoj MySQL bazi. U tabeli se cuvaju hostovi tih klijenata, pa se keywordi rasporedjuju na onoliko masina koliko ih ima u procesu. Ne pretereno inteligentno, ali moze se skalirati sa dodavanje novih servera i sl.
E sad, ista stvar bi mogla i preko SOAP-a recimo, gde je na glavnoj masini SOAP server prima zahteve od ovih SOAP klijenata, ali obzirom da nemam PHP5 na tom serveru, nisam zeleo da se bakcem sa starim (PEAR SOAP ili NUSoap) bilbiotekama.
|
Kao sto sam i pretpostavljao - nemam pojma o LAMP-u :1043: Znao sam da moze da se koristi SOAP, ali za ovo ostalo nisam (npr. socket server). Hvala na pointerima! |
| ivanhoe |
18. 09. 2006. 23:31 |
ja o .netu imam samo blagu predstavu, ali evo prica moje najbolje ortakinje o "skalabilnim distribuiranim microsoft resenjima". Ona radi u firmi koja treba da uradi neki software za jednu veliku (drzavnu) firmu u crnoj gori. Potrebno je odraditi upis u 2 baze, pri cemu ID-jevi u obe baze moraju da budu isti, znaci sve mora ili da uspe na obe ili da se ne uradi (znaci distribuirana transakcija).
Ja sam joj predlozio jednostavno (php logic) resenje sa skriptom koja otvori 2 transakcije, upise u jednu bazu , upise u drugu, i tek ako je sve uspelo commituje. Tako bi se to uradilo u php-u. Medjutim njene kolege proglase kako takvo resenje nije dovoljno inzenjersko i odluce da koriste nekakvu MS gotovu (i besplatnu) COM+ proxy komponentu koja omogucava distribuiranu transakciju na 2 baze. Kao sto rekoh ja se ne razumem u .Net, tako da ne znam sve detalje ( i pola nisam ni razumeo kako tacno radi), ali iz njene price ta komponenta je puna bagova, ljudi se masovno po netu zale, i trebalo im je sto godina da urade da to radi. Onda se lepo spakuju u avion i odu u CG da instaliraju software, ali on nece tamo ni da mrdne. Vrate se nazad i kod njih u mrezi sve radi. Ispostavi se na kraju da to njihovo resenje ne ume da radi kad se baze nalaze na dve razlicite mreze (jedna je lokalna (preko VPN-a), a druga je preko interneta. Ako su na istoj radi super, ali ovako jednostavno ne ume...
I sad lupaju glavu sta da rade, potrosili su gomilu vremena u razvoju ovog resenja, a na kraju ce da zavrse radece jednostavno rucno, umesto sa gotovim resenjima...
I da ne ispadne neki advocacy, samo hocu da istaknem cinjenicu koja je vazila jos iz vremena VB4... gotova resenja su divna stvar ako je problem koji se resava unutar onog predvidjenog od strane autora. Ali ako ne rade kako je predvidjeno mozes da se ubijes, jer nemas pojma gde je problem i generalno ne mozes obicno ni da ga ispravis i da hoces jer je konceptualno ugradjen u samo gotovo resenje...
Off Topic:
Uzgred, ako neko zna kako da se resi ovaj problem efikasno u .Netu, pomagajte, imacete vecnu zahvalnost i pice po izboru od moje ortakinje :)
|
| dinke |
18. 09. 2006. 23:44 |
Off Topic:
Citat:
Originalno napisao ivanhoe
Uzgred, ako neko zna kako da se resi ovaj problem efikasno u .Netu, pomagajte, imacete vecnu zahvalnost i pice po izboru od moje ortakinje :)
|
Sa koliko ništica iza prve cifre iskazujete večnu zahvalnost ;)
|
| degojs |
19. 09. 2006. 01:24 |
Citat:
ivanhoe:
Ja sam joj predlozio jednostavno (php logic) resenje sa skriptom koja otvori 2 transakcije, upise u jednu bazu , upise u drugu, i tek ako je sve uspelo commituje. Tako bi se to uradilo u php-u.
|
Čekaj, da li to podrazumeva da imaš dve različite konekcije do dva db servera (naravno vredi stara napomena: ne znam PHP :) )? Ako je tako, mislim da imaš problem:
1. prva konekcija do prve baze/server1, startuješ prvu transakciju
2. uradiš sve sa prvom, ali bez commit
3. druga konekcija do druge baze/server2, startuješ drugu transakciju
4. uradiš sve sa drugom
5. commit druge transakcije - uspešan.
6. commit prve pukao
7. treba da uradiš rollback druge, kako?
(Rešenje ti je za .NET linkovao Dragi Tata). |
| degojs |
19. 09. 2006. 01:40 |
OT:
Citat:
dinke:
od ovih J2EE linkova sto je DT postavio mi se dize kosa na glavi od terminologije
|
I nisi jedini (mada, terminologija je naravno nista, ucenje samog programiranja zahteva dosta vremena i paznje :) ) --- Sun je takodje priznao da je j2ee "overengineered" te su u poslednjoj veziji (Java EE) mnogo radili da pojednostave programiranje. Kazu ljudi da su lepo odradili stvar, a vreme ce pokazati da li je to tacno.. Ja trenutno citam EJB 3, pre spavanja naravno ;)
P.S.
Dinke, kako stavis tekst u OT? |
| ivanhoe |
19. 09. 2006. 02:08 |
Citat:
Originalno napisao dinke
Off Topic:
Sa koliko ništica iza prve cifre iskazujete večnu zahvalnost ;)
|
nistica mozes da dobijes koliko zelis, ali prva cifra ce biti problem :) |
| dedamunila |
19. 09. 2006. 02:44 |
Citat:
Originalno napisao degojs
Čekaj, da li to podrazumeva da imaš dve različite konekcije do dva db servera (naravno vredi stara napomena: ne znam PHP :) )? Ako je tako, mislim da imaš problem:
1. prva konekcija do prve baze/server1, startuješ prvu transakciju
2. uradiš sve sa prvom, ali bez commit
3. druga konekcija do druge baze/server2, startuješ drugu transakciju
4. uradiš sve sa drugom
5. commit druge transakcije - uspešan.
6. commit prve pukao
7. treba da uradiš rollback druge, kako?
(Rešenje ti je za .NET linkovao Dragi Tata).
|
+1. Odgovor na 7. - nikako :1027: (ako je u pitanju prava ACID transakcija)
@Ivanhoe, ovo ima potencijal da bude jako opasno. Da bi ovako nesto funkcionisalo, potrebno je parce middleware-a (tipicno poznato pod imenom "transaction monitor" ili "transaction coordinator") koje koordinira transakcije, tipicno pomocu 2PC protokola, koje je jako teško simulirati "u domacoj radinosti". Konkretno, ako su u pitanju vazni podaci (recimo o novcanim transakcijama), preporucujem ti da to nikako ne radis. Ali sta sad, zivot pise pravila :1064: |
| dedamunila |
19. 09. 2006. 02:48 |
Citat:
Originalno napisao ivanhoe
Medjutim njene kolege proglase kako takvo resenje nije dovoljno inzenjersko i odluce da koriste nekakvu MS gotovu (i besplatnu) COM+ proxy komponentu koja omogucava distribuiranu transakciju na 2 baze. Kao sto rekoh ja se ne razumem u .Net, tako da ne znam sve detalje ( i pola nisam ni razumeo kako tacno radi), ali iz njene price ta komponenta je puna bagova, ljudi se masovno po netu zale, i trebalo im je sto godina da urade da to radi. Onda se lepo spakuju u avion i odu u CG da instaliraju software, ali on nece tamo ni da mrdne. Vrate se nazad i kod njih u mrezi sve radi. Ispostavi se na kraju da to njihovo resenje ne ume da radi kad se baze nalaze na dve razlicite mreze (jedna je lokalna (preko VPN-a), a druga je preko interneta. Ako su na istoj radi super, ali ovako jednostavno ne ume...
|
Kao sto rekoh, nisam skoro otvarao COM+ konzolu, ali ovakve stvari bi trebalo da rade, ukoliko baza (ili neki drugi resurs, recimo message queue) podrzava nekakav "2-phase commit" protokol po nekoj specifikaciji cijeg imena ne mogu da se setim :1074: Sve transakcije koje automatski vrsi COM+ rade pomoću nakavog DTC-a (da ne sirim pricu) koji, zajedno sa COM+ koristi nekakvu tonu portova koju ni najveci ludaci ne drze otvorenim. Tako da je ideja o "bazi na Internetu" i COM+ transakcijama (ako sam dobro razumeo), blago receno, naivna. Mada, realno, cak i bez COM+ u celoj prici, cisto sumnjam da bi iko u normalnoj situaciji ostavio database server ispred firewall-a. Moguce je da sam nesto pogresno razumeo. |
| ivanhoe |
19. 09. 2006. 03:38 |
Citat:
Originalno napisao dedamunila
Mada, realno, cak i bez COM+ u celoj prici, cisto sumnjam da bi iko u normalnoj situaciji ostavio database server ispred firewall-a. Moguce je da sam nesto pogresno razumeo.
|
Nije moj projekat pa ne znam detalje, ali ta baza mora da bude na netu da bi partneri mogli da se kache iz celog sveta. Verovatno imaju firewall koji dopusta pristup samo nekim IP-jevima, to bi bio neki normalan pristu, ali kazem ne znam detalje tacno. Znam samo da imaju grdnih problema da to naprave to da radi tako. Dok god su im obe baze unutar iste (lokalne) mreze, sve im radi... |
| ivanhoe |
19. 09. 2006. 03:45 |
Citat:
Originalno napisao degojs
Čekaj, da li to podrazumeva da imaš dve različite konekcije do dva db servera (naravno vredi stara napomena: ne znam PHP :) )? Ako je tako, mislim da imaš problem:
1. prva konekcija do prve baze/server1, startuješ prvu transakciju
2. uradiš sve sa prvom, ali bez commit
3. druga konekcija do druge baze/server2, startuješ drugu transakciju
4. uradiš sve sa drugom
5. commit druge transakcije - uspešan.
6. commit prve pukao
7. treba da uradiš rollback druge, kako?
|
U pravu si, jedino rucno brisanje moze u tom slucaju.
a kako se tacno ovo resava u .Net-u? Ne mislim kako ti to pokrenes u svom programu, nego kako se interno realizuje distribuirana transakcija unutar komponente? Isto nekako mora da se simulira software-ski? Ili baza ima neki svoj mehanizam za ovo?
EDIT: zapravo moze ovo na mysql5-ci da se uradi, to se zove XA transaction, upravo nadjoh help:
http://dev.mysql.com/doc/refman/5.0/en/xa-states.html |
| degojs |
19. 09. 2006. 07:14 |
Citat:
ivanhoe:
Nije moj projekat pa ne znam detalje, ali ta baza mora da bude na netu da bi partneri mogli da se kache iz celog sveta. Verovatno imaju firewall koji dopusta pristup samo nekim IP-jevima, to bi bio neki normalan pristu, ali kazem ne znam detalje tacno. Znam samo da imaju grdnih problema da to naprave to da radi tako. Dok god su im obe baze unutar iste (lokalne) mreze, sve im radi...
|
To bi moglo jednostavno da se resi na 2 nacina:
1. ukljuci se IPSec enkripcija/filterovanje u Windowsu
2. VPN |
| dinke |
19. 09. 2006. 08:37 |
@degojs
Za offtopic koristi:
[offtopic]
ovde ide offtopic
[/offtopic]
|
| dedamunila |
19. 09. 2006. 11:08 |
Citat:
Originalno napisao ivanhoe
|
Nisam citao clanak, ali to bi trebalo da je to, taj XA je jedan standarda koji se koriste za distribuirane transakcije. Posto ga MySQL podrzava, sada bi trebalo da i, npr., COM+ moze da ga ukljuci (ili "enlist"-uje, u zargonu :) u svoje (eventualno distribuirane) transakcije. |
| dedamunila |
19. 09. 2006. 11:14 |
Citat:
Originalno napisao degojs
To bi moglo jednostavno da se resi na 2 nacina:
1. ukljuci se IPSec enkripcija/filterovanje u Windowsu
2. VPN
|
Da, ali cak ni VPN ne mozes da uzmes for granted, neki ni njega ne dozvoljavaju. Kada bih ja imao slobodu da biram kako uciniti podatke dostupnim partnerima, prvo bih razmotrio SOAP. |
| Dragi Tata |
19. 09. 2006. 13:38 |
Citat:
Originalno napisao dedamunila
Nisam citao clanak, ali to bi trebalo da je to, taj XA je jedan standarda koji se koriste za distribuirane transakcije. Posto ga MySQL podrzava, sada bi trebalo da i, npr., COM+ moze da ga ukljuci (ili "enlist"-uje, u zargonu :) u svoje (eventualno distribuirane) transakcije.
|
Ali to samo znači da MySQL može da učestvuje u COM+ distribuiranim transakcijama. I dalje mi nije jasno kako LAMP može da odradi tako nešto. |
| dinke |
19. 09. 2006. 15:42 |
Citat:
Originalno napisao Dragi Tata
Ali to samo znači da MySQL može da učestvuje u COM+ distribuiranim transakcijama. I dalje mi nije jasno kako LAMP može da odradi tako nešto.
|
Pa, hm mislim ono ...
LAMP = Linux Apache MySQL PHP :1064: |
Off Topic:
@skaarj, dedamunila
Aha, sad mi je jasnije. Thanks.
|
| ivanhoe |
19. 09. 2006. 17:26 |
Citat:
Originalno napisao Dragi Tata
Ali to samo znači da MySQL može da učestvuje u COM+ distribuiranim transakcijama. I dalje mi nije jasno kako LAMP može da odradi tako nešto.
|
Evo sta oni kazu:
Citat:
The point is that all the data sources have to conform to the XA protocol. All of the data sources must be able to play the following game:
- start distributed transaction: XA START
- recieve commands from the application: SELECT, INSERT, getCustomers(), createCustomer(), ...
- close the list of commands: XA END
- make a commitment that the requested actions *can* be commited: XA PREPARE
Then the application collects the XA PREPARE response values from all data sources and decides about commit or rollback. For example, all data sources have send positive replies to XA PREPARE and the application decides to commit all subtransactions. Then it has to send out XA COMMIT to all data sources.
Neither the MySQL Server nor PHP care how many different XA compatible data sources participate in that game. And they also do not care what kind of XA compatible data sources belong to the distributed transactions: MySQL, Oracle, ... - whatever.
|
|
| Dragi Tata |
19. 09. 2006. 17:49 |
Citat:
Originalno napisao dinke
Pa, hm mislim ono ...
LAMP = Linux Apache MySQL PHP :1064:
|
Ovde neko nekog zeza :)
Ako imaš recimo J2EE aplikacioni server kao što je JBOSS, onda MySQL može da učestvuje u distribuiranim transakcijama, ali je transaction manager JBOSS a ne MySQL.
U .NET svetu imaš Enterprise Services (u stvari, stari dobri MTS zamotan u nekoliko oblandi :) ) koji takođe radi kao transaction manager (između ostalog)
Moje pitanje je: ima li "nešto" u LAMP svetu što može da odigra ulogu transaction managera? Koliko mi se čini, (L)inux je prosto-naprosto OS, (A)pache je web server, (M)ySQL je dbms i po prirodi stvari ne može, (P)HP ne može.
Stvarno nemam nameru da "advokatišem", nego me interesuje šta "lampaši" rade u takvim situacijama. |
| ivanhoe |
19. 09. 2006. 20:36 |
pa generalno se lampasi vrlo retko srecu sa ovim....ne postoji gotov transaction manager za php, prevashodno jer se ovakve stvari vrlo retko koriste na sajtovima, a mysql podrska je vrlo sveza, ali ti uvek mozes da odradis tu logiku u svojoj skripti ako ti je potrebna..
Transaction manager je svakako zgodan interfejs izmedju tebe i funkcionalnosti ugradjene u bazu, ali bitna stvar je (koliko sam ja razumeo) da baza obezbedjuje to. Sta bi tebe sprecavalo da odradis u skripti isto sto je tamo neki programer odradio pisuci taj transact. manager ? Nije to mali posao, i lepse bi bilo da je neki opaki baja programer to vec napisao i testirao, pa da ne moras ti da se sekiras oko toga, ali sasvim je izvodljivo i ovako...
|
| Ilija Studen |
19. 09. 2006. 21:11 |
Zanimljiva stvar što se problem koji se ovde pominje teški raritet kad je web dev u pitanju. Ono na šta LAMP pruža odlične odgovore je kako napraviti nešto kao Yahoo!, Wikipedia, Flickr, kako napraviti aplikaciju za opštu webmaster popularciju koja će se lako instalirati, održava i ne ubija server (Invision, vBulletin, WordPress, Textpattern, Flyspray etc), kako napraviti jednostavan CMS za kompanijski website, kako nabrzaka sklepati sajt za malu online zajednciu, kako sa jednim programerom i jednim dizajnerom uz malo magije napraviti web servis koji je poslovno održiv itd itd itd.
Distribuirane transakcije? WTF??? Da pitam PHP ekipu sa foruma: kad ste se prvi put sreli sa ovim pojmom? Koliko puta u životu vam je tako nešto trebalo? Da li ne možete da spavate jer se LAMP ne snalazi lepo u toj situaciji (ja ću posle ove diskusije imati ozbiljnih problema sa nesanicom, osećam ;) )?
Nije bitno koliko stvari neka platforma radi, bitno je da one koje radi radi odlično. A LAMP se prilično lepo pokazao u praksi.
|
| Ilija Studen |
19. 09. 2006. 21:36 |
Btw, izvinjavam se za offtopic post. Nije bilo pitanje da li LAMP treba da podržava tako nešto, već da li podržava, a odgovor je NE koliko sam razumeo. Samo sam hteo da kažem da je navedeni problem potupuno nebitan za 99.999% LAMP developera, a oni kojima je bitan će ili koristiti platformu koja se lepo snalazi u takvoj situaciji ili će skuckati nešto što radi zadovoljavajuće dobro (ako je "zadovoljavajuće" prihvatljivo za konkretan problem, negde mora da bude "savršeno").
|
| dinke |
19. 09. 2006. 21:44 |
Citat:
Originalno napisao Dragi Tata
Ovde neko nekog zeza :)
|
Pa dobro, malo sam se nasalio, posto se LAMP uzima kao celo okruzenje u kome PHP obicno radi, a ti si mislio iskljucivo na PHP (a sve vreme pricas LAMP) :)
Elem, ne znam sta bih sustinski novo rekao, a da Ilija nije napisao u prethodna dva posta (mozda bi ja to malo lepse uvio u oblande, ali to je to) ;) |
| Dragi Tata |
19. 09. 2006. 21:48 |
Citat:
Originalno napisao dinke
Pa dobro, malo sam se nasalio, posto se LAMP uzima kao celo okruzenje u kome PHP obicno radi, a ti si mislio iskljucivo na PHP (a sve vreme pricas LAMP) :)
|
Mislio sam LAMP, u smislu tehnologija. Ne bih ni očekivao da su takve stvari ugrađene direktno u PHP, već da postoji neki "app server" koji bi to obezbeđivao a koji bi bio deo LAMP tehnologije.
U svakom slučaju, hvala na informacijama. |
| caboom |
20. 09. 2006. 09:54 |
Citat:
Originalno napisao Ilija Studen
Distribuirane transakcije? WTF??? Da pitam PHP ekipu sa foruma: kad ste se prvi put sreli sa ovim pojmom? Koliko puta u životu vam je tako nešto trebalo? Da li ne možete da spavate jer se LAMP ne snalazi lepo u toj situaciji (ja ću posle ove diskusije imati ozbiljnih problema sa nesanicom, osećam ;) )?
Nije bitno koliko stvari neka platforma radi, bitno je da one koje radi radi odlično. A LAMP se prilično lepo pokazao u praksi.
|
pa u sustini, ovo je delimicno tacno, ali mi zvuci kao genericki odgovor za bilo koje slovo u akronimu LAMP kada se pomene neki feature koji bi zgodno imati, ili koje druge platforme imaju i po 10tak godina. u sustini sve je moguce simulirati, zaobici, itd. svaki problem ima N resenja, ali je poenta da iskusne arhitekte/developeri obicno posezu za takvim resenjima, koje je svakako moguce zaobici, zato da bi smanjili entropiju koju svaki "workaround" unosi sa svojim cornercase-ovima, ne zato sto je neko od njih nesposoban da razmislja van hype termina. of korz, ovo ne znaci da LAMP nije dobro resenje za dobar deo problema, ali ne i za svaki. uostalom, na kraju se, kao i obicno, svede na to da uzmes papir i olovcicu i svedes cenu developmenta znajuci sve prednosti i mane tehnologije, ili kao u vecem broju slucajeva - management dodje i zahteva tacno odredjenu tehnologiju. |
| Dragi Tata |
21. 09. 2006. 14:41 |
Upravo sam našao bolji članak o distribuiranim transakcijama u .NET okruženju, uz kratko objašnjenje čemu sve to služi. http://www.codeproject.com/csharp/ESTransactions.asp
Inače, razlog što sam potegao ovu temu je to što upravo radimo na redizajnu jedne aplikacije od "monolitne" u distribuiranu. Problem sa kojim se non stop srećem je da za C++ postoje mnoge gotove middleware komponente (naravno, nije sve tako kompletno i lepo integrisano kao u .NETu ili Javi) ali ljudi vole da pišu sve iz početka iz razloga koje nikako ne mogu da shvatim. Rezultat je obično gomila bagova i probijanje rokova. Još pre 5 godina sam se zarekao da ću da koristim gotove komponente kad god je to moguće, ali priča se ponavlja - većina smatra da je "lako" to isprogramirati iz početka.
Uostalom, što kaže naš narod: "veži konja gde ti gazda kaže" :1074: |
| ivanhoe |
21. 09. 2006. 23:51 |
Citat:
Originalno napisao caboom
pa u sustini, ovo je delimicno tacno, ali mi zvuci kao genericki odgovor za bilo koje slovo u akronimu LAMP kada se pomene neki feature koji bi zgodno imati, ili koje druge platforme imaju i po 10tak godina.
|
pa dobro red je onda da se pomene i mod_rewrite i gzipovanje sadrzaja strana, mod_proxy, mod_security i druge stvari koje lamp ima vec jako dugo, a IIS tek od nedavno (i nepotpuno..). To su sve daleko potrebnije svakodnevne stvari od distribuiranih transakcija, zar ne?
Mada ja licno sam pristalica toga da treba birati alat prema poslu, a ne obrnuto. A evo kupio sam i "ASP.Net in C#" knjigu na proslom sajmu knjiga, stoji mi na stolu i skuplja prasinu, nikako da skupim vremena da krenem da ucim :) Ali hocu, sto da ne... ako nista drugo da mogu da napadam "vas MS-ovce" argumentovano :))) |
| caboom |
22. 09. 2006. 13:58 |
Citat:
Originalno napisao ivanhoe
pa dobro red je onda da se pomene i mod_rewrite i gzipovanje sadrzaja strana, mod_proxy, mod_security i druge stvari koje lamp ima vec jako dugo, a IIS tek od nedavno (i nepotpuno..). To su sve daleko potrebnije svakodnevne stvari od distribuiranih transakcija, zar ne?
|
u neku ruku da, mada sam vise upirao prstom na php i mysql, koji su, bar prema meni, najbolnije tacke LAMP stack-a. ovo je svakako ok stack za 90-95% web aplikacija, ali npr. famozno "lako horizontalno" skaliranje postaje problem sa sesijama i imas izbor ili da pravis hack-na-hack i koristis cesto nedovoljno proverene komponente, ili se ispruzis za solidnu kolicinu para za neko od HA resenja... u svakom slucaju, problem je u onih 5-10% na koje pre ili kasnije naletis i slucaju koji DT pominje, a to je sto iako je daleko zabavnije sve baciti u vodu i napisati sve od nule to cesto predstavlja idealan nacin da probijes sve rokove, dodao bih samo da i nedovoljno proverene komponente koje dobro rade samo u odredjenom broju slucajeva - ovo je cesto daleko teze primetiti i obicno daleko opasnije za "career path", ovo je npr. slucaj sa velikim brojem opensource komponenti, pogotovo u middleware-u. sa druge strane, tih famoznih 5-10% su obicno daleko zanimljiviji i ambiciozniji projekti oko kojih se neretko vrti daleko veca kolicina $$. :) |
| Ilija Studen |
22. 09. 2006. 14:01 |
Citat:
Originalno napisao caboom
famozno "lako horizontalno" skaliranje postaje problem sa sesijama i imas izbor ili da pravis hack-na-hack i koristis cesto nedovoljno proverene komponente
|
Sorry, ne stoji. Ti možeš da promeniš način na koji se sesije čuvaju i čuvaš ih recimo u bazi (nije hack već podržan feature). LAMP se stvarno lako širi horizontalno...
Evo ga i link: http://www.php.net/manual/en/functio...ve-handler.php |
| caboom |
22. 09. 2006. 14:33 |
Citat:
Originalno napisao Ilija Studen
|
ok, ali imas odredjene limite i sta ako baza ode down? (mysql cluster?) i opet moras da napises wrapper funkcije. u sustini, nemoj pogresno da me shvatis, ne kazem da php nije skalabilan, u krajnjem slucaju, sve je skalabilno sa odredjenom cenom - ali mislim da je "laka skalabilnost" mit. |
| Vreme je GMT +2. Trenutno vreme je 10:10. |
|
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.
Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.
