[ALG] kan dit ooit verkeerd gaan?

[codemann]

[SERVER1]
- PHP script dat requests doorstuurt naar server 2 en zo lang een request in verwerking is de nieuwe requests in een queue stopt

[SERVER2]
- ASP script 1 dat de requests binnenkrijgt, verwerkt, server 1 laat weten als ze verwerkt zijn en in de database op server 1 zet dat de request verwerkt is;
dit script begint met te controleren of de status van de te verwerken request in de database op server 1 nog altijd op niet verwerkt staat en als dit niet is zet het de status op verwerkt.
- ASP script 2 dat om de minuut uitgevoerd wordt en gaat kijken in de database op server 1 of zeker alle requests doorgekomen zijn en verwerkt zijn, anders roept het ASP script 1 op zodat deze niet verwerkte requests nog verwerkt worden

---

ASP script 2 wil ik gebruiken om zeker te zijn dat door een reboot van een server of weet ik veel welke kleine fout er problemen kunnen ontstaan.
Mijn vraag is ben ik zeker dat als ik ASP script 1 begin met een controle dat dan geen berichten dubbel verwerkt kunnen worden? Aangezien de requests kunnen gestuurd worden via het PHP script en ASP script 2 is dit misschien wel mogelijk.

[NMe]

Alles kan in principe fout gaan, en dat moet je gewoon als programmeur proberen in te schatten en op te vangen. Je ontwerp zal vast wel goed te implementeren zijn, maar dat wil niet zeggen dat er niets fout KAN gaan...

[Alarmnummer]

NMe84 schreef op 20 april 2004 @ 11:38:
Alles kan in principe fout gaan, en dat moet je gewoon als programmeur proberen in te schatten en op te vangen. Je ontwerp zal vast wel goed te implementeren zijn, maar dat wil niet zeggen dat er niets fout KAN gaan...

Ik denk dat je een heel eind kan komen met transacties, daarbij is het per definitie een alles of niets situaties. Eventueel zou je moeten werken met gedistribueerde transacties doordat je dus meerdere bronnen op verschillende locaties hebt.

[Verwijderd]

codemann schreef op 20 april 2004 @ 11:15:
[SERVER1]
- PHP script dat requests doorstuurt naar server 2 en zo lang een request in verwerking is de nieuwe requests in een queue stopt

[SERVER2]
[...]
- ASP script 2 dat om de minuut uitgevoerd wordt en gaat kijken in de database op server 1 of zeker alle requests doorgekomen zijn en verwerkt zijn, anders roept het ASP script 1 op zodat deze niet verwerkte requests nog verwerkt worden

[...]
Mijn vraag is ben ik zeker dat als ik ASP script 1 begin met een controle dat dan geen berichten dubbel verwerkt kunnen worden? Aangezien de requests kunnen gestuurd worden via het PHP script en ASP script 2 is dit misschien wel mogelijk.

Je kan een extra status meegeven aan een request, zodat je kan zien welke nog niet verwerkt zijn, welke verwerkt zijn, en welke op het moment verwerkt worden.

Ook dit is niet 100% waterdicht, maar je komt er net een stukje verder mee denk ik

[curry684]

Alarmnummer schreef op 20 april 2004 @ 11:41:
[...]

Ik denk dat je een heel eind kan komen met transacties, daarbij is het per definitie een alles of niets situaties. Eventueel zou je moeten werken met gedistribueerde transacties doordat je dus meerdere bronnen op verschillende locaties hebt.

Ik zou persoonlijk meer voor een 3-tier systeem kiezen dan voor distributed transacties. Bouw op server 2 een queue manager (middle tier) waar beide webservers (en alle toekomstige webservers!!!) hun requests blind op dumpen en laat die queue manager middels transactions de data-integriteit naar de database bewaken (die je middels deze opzet ook kunt moven).

[Alarmnummer]

curry684 schreef op 20 april 2004 @ 12:30:
[...]
Ik zou persoonlijk meer voor een 3-tier systeem kiezen dan voor distributed transacties. Bouw op server 2 een queue manager (middle tier) waar beide webservers (en alle toekomstige webservers!!!) hun requests blind op dumpen en laat die queue manager middels transactions de data-integriteit naar de database bewaken (die je middels deze opzet ook kunt moven).

Dat neemt niet weg dat je nog steeds gebruikt kunt maken van een gedistribueerde transacties hoor. Als je MOM (Message Oriented Middleware) gebruikt zoals JMS implementaties of MSMQ dan kan je daar ook fijn gebruik maken van transacties. Aangezien je meerdere transactionele bronnen aanspreek (database, message queue etc) doe je er verstandig aan om dit allemaal over 1 master transactie te laten verlopen. Hierdoor hou je de alles of niets functionaliteit.

In jouw geval kan het voorkomen dat je een message van de message server ophaalt om te gaan verwerken, en voordat je hebt gecommit naar de db, dat de server crashed. Je hebt dan wel een probleem aangezien je nu 1 message kwijt bent.

[ Voor 18% gewijzigd door Alarmnummer op 20-04-2004 13:21 ]

[Soultaker]

Ik denk dat het er een beetje vanaf hangt of het kwaad kan om een bericht meerdere malen te 'verwerken' . Als de message queue server gewoon de database beheert hoeven er nooit berichten verloren te raken; de message queue server geeft dan messages aan de verwerkende processen en markeert de berichten pas als verwerkt als het verwerkende proces aangeeft er mee klaar te zijn.

Als de message queue server crasht, dan kan het verwerkende proces niet verder en kan een verwerkt bericht niet als verwerkt aangemerkt worden. Na een restart is de kans dus groot dat het bericht opnieuw verwerkt wordt, tenzij het server proces netjes z'n resultaten vasthoudt totdat ze door de server verwerkt zijn. Als het verwerkende proces crasht, dan is het niet duidelijk of een bericht geheel of gedeeltelijk verwerkt is. Dat hangt een beetje van de aard van de verwerking af (in hoeverre is het atomair uit te voeren?).

[Alarmnummer]

Soultaker schreef op 20 april 2004 @ 13:45:
Ik denk dat het er een beetje vanaf hangt of het kwaad kan om een bericht meerdere malen te 'verwerken'.

Hmm.. ze mogen hetzelfde geldstort bericht voor mij wel vaker verwerken Ik denk dat het geen goeie zaak is om hiervan uit te gaan. Voor sommige dingen maakt het niet zoveel uit hoor, zoals bv voor een webserver, maar voor andere dingen kan het wel erg veel uitmaken.

Als de message queue server gewoon de database beheert hoeven er nooit berichten verloren te raken; de message queue server geeft dan messages aan de verwerkende processen en markeert de berichten pas als verwerkt als het verwerkende proces aangeeft er mee klaar te zijn.

Op het moment dat een bericht belangrijk is (zoals het storten van geld) dan wil je dat dit bericht of klaar staat op de message queue, of is verwerkt. Als het bericht nog niet is verwerkt, en je maakt geen gebruik van een serieuze message queue (met transactions en persitance) dan heb je een groot probleem als de server (of message server) crashed omdat je dan berichten kwijt raakt. Het zou vervelend voor mij zijn als dat stortingsbericht nooit verwerkt wordt.

Als de message queue server crasht, dan kan het verwerkende proces niet verder en kan een verwerkt bericht niet als verwerkt aangemerkt worden.Na een restart is de kans dus groot dat het bericht opnieuw verwerkt wordt, tenzij het server proces netjes z'n resultaten vasthoudt totdat ze door de server verwerkt zijn. Als het verwerkende proces crasht, dan is het niet duidelijk of een bericht geheel of gedeeltelijk verwerkt is. Dat hangt een beetje van de aard van de verwerking af (in hoeverre is het atomair uit te voeren?).

Je weet niet wat het verwerkende proces ook allemaal uitvreet. Misschien post hij op een andere message queue een nieuwe message. Als dit niet met een gedistribueerde transactie is afgescherm dan kan het voorkomen dat een bericht gelezen wordt, een nieuwe bericht op een andere server wordt geplaatst en voordat het 1e bericht als gelezen is gemarkeert, dat er een crash plaats vind.

[edit]
vette aanrader:
Enterprise Integration Patterns : Designing, Building, and Deploying Messaging Solutions

De aanvulling op Patterns of Enterprise Application Architecture

[ Voor 12% gewijzigd door Alarmnummer op 20-04-2004 14:03 ]

[Alarmnummer]

*kick*