[PHP/MYSQL] foutmelding bij groot aantal mysql queries

[AtlonXP1800]

Ik heb een probleempje met het uitvoeren van een groot aantal mysql queries achter elkaar.
Ik heb een webservice gemaakt, deze webservice moet er voor zorgen dat 2 databases synchroon met elkaar worden gehouden.

Als in de ene applicatie een wijziging wordt gedaan, dan roept deze een webservice aan, die de gewijzigde gegevens ontvangt en de wijziging doorvoert in de mysql database.

De code die ik gebruik voor de webservice is deze (gesimplificeerd):

code:

class MySoapServer
{
    public function updaterecord ($param1, $param2)
    {
        //Zet connectie op
        $dsn = 'mysql:host=hostname;dbname=dbname';
        $dbh = new PDO($dsn,'username','password');

        $sql = "update `table1` set `param1`    =   '$param1'   where `param2` = '$param2'";                    
    
        $affected_rows = $dbh->exec($sql);

        $dbh = null; //verbreek verbinding
        return $affected_rows;
    }
}

$options = array('uri' => 'http://serverx/soapserver.php');
$server = new SoapServer(null,$options);
$server->setClass('MysoapServer');
$server->handle();

Dit werkt prima, als ik in de aanroepende applicatie 200 records tegelijk wijzig wordt de webservice 200x aangeroepen en worden de wijzigingen prima doorgevoerd.

Wat helaas niet goed gaat is erg grote aantallen. het zou in theorie mogelijk kunnen zijn dat er 10.000 records tegelijk worden gewijzigd in de aanroepende applicatie. Probeer ik dat, dan gaat het fout. In mijn logfiles zie ik dan de volgende melding terug:

PHP Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[HY000] [2003] Can't connect to MySQL server on 'localhost' (10048)

Kennelijk kan mysql het grote aantal queries achter elkaar niet aan.
Idealiter zou ik alle update in 1x doen (bijvoorbeeld met een transactie) maar doordat ze stuk voor stuk door de webservice komen is dit niet mogelijk.

Heeft iemand enig idee hoe dit wel goed zou kunnen?

[Mike2k]

Uhh..waarom moet je voor ELKE query een nieuwe database connectie maken ?
Daar gaat het fout...

Je db connectie zet je bijv in de __autoload constructor.

Oftewel, zodra je de class instantieert maakt hij een verbinding naar de db.
Daarna ga je queries uitvoeren.
En dan verbreek je de verbinding...

[MueR]

Met Fastex. Je gaat grandioos over de max_connections in mysql heen, waardoor die gewoon tegen je zegt dat je op kan hoepelen. Mag ik vragen waarom je een functie heb geschreven, om er vervolgens maar gewoon Class{} omheen te klappen?

[curry684]

AtlonXP1800 schreef op woensdag 15 juli 2009 @ 14:18:
Idealiter zou ik alle update in 1x doen (bijvoorbeeld met een transactie) maar doordat ze stuk voor stuk door de webservice komen is dit niet mogelijk.

Je zou natuurlijk ook gewoon voor bulk updates een bulkupdaterecord functie kunnen toevoegen. Zal iets beter performen dan 10.000 serialized SOAP-RPC calls.

edit:
ik zou trouwens het adres van je SOAP-server niet aan teveel mensen geven, voor je het weet is je database weg....

[ Voor 13% gewijzigd door curry684 op 15-07-2009 14:41 ]

[AtlonXP1800]

Fastex schreef op woensdag 15 juli 2009 @ 14:22:
Uhh..waarom moet je voor ELKE query een nieuwe database connectie maken ?
Daar gaat het fout...

Je db connectie zet je bijv in de __autoload constructor.

Oftewel, zodra je de class instantieert maakt hij een verbinding naar de db.
Daarna ga je queries uitvoeren.
En dan verbreek je de verbinding...

Elke call naar de webservice komt natuurlijk als losse call binnen, maw, elke call instantieert de class, en deze instance wordt dus weer vernietigd aan het einde van de call naar de webservice.
Volgens mij heeft het dan vrij weinig nu iets in de constructor te gaan zetten, want ook dan zal er voor elke call een nieuwe database connectie op worden gezet.

Helaas kan ik vanuit de applicatie die de aanroep stuurt alleen per record een call doen (soort van trigger zeg maar), en niet voor een bulk.

MueR schreef op woensdag 15 juli 2009 @ 14:27:
Met Fastex. Je gaat grandioos over de max_connections in mysql heen, waardoor die gewoon tegen je zegt dat je op kan hoepelen.

Is dat zo? elke connectie wordt ook weer gesloten. Max_connections staat op 100, voer is er 1000 records doorheen, dan gaat het prima.

Mag ik vragen waarom je een functie heb geschreven, om er vervolgens maar gewoon Class{} omheen te klappen?

Om in de toekomst makkelijk uit te kunnen breiden (in het echte script zitten die procedurele regels trouwen niet in de class file er bij)

[ Voor 26% gewijzigd door AtlonXP1800 op 15-07-2009 14:56 ]

[AtlonXP1800]

curry684 schreef op woensdag 15 juli 2009 @ 14:39:

edit:
ik zou trouwens het adres van je SOAP-server niet aan teveel mensen geven, voor je het weet is je database weg....

mwah, als iemand de database op localhost wil wissen wens ik hem veel succes

[cariolive23]

Ik heb een webservice gemaakt, deze webservice moet er voor zorgen dat 2 databases synchroon met elkaar worden gehouden.

Een webservice is véél te langzaam, met een klein beetje belasting op de master, loopt de slave al een heel eind achter. En dat probleem wordt alleen maar groter.

Gebruik echte replicatietools, daarmee is replicatie mogelijk. Met een webservice gaat je dit echt niet lukken, tenzij de database nauwelijks wordt gebruikt.

Ik dacht dat MySQL standaard een soort van replicatie in huis had, al heb ik er nooit mee gewerkt. Je kunt uiteraard ook middleware gebruiken, kijk dan eens naar Sequoia.

[Mike2k]

Dan is het overall design van je app m.i. niet in orde...

Wat helaas niet goed gaat is erg grote aantallen. het zou in theorie mogelijk kunnen zijn dat er 10.000 records tegelijk worden gewijzigd in de aanroepende applicatie.

Als jij 10.000 records in 1 keer wijzigt, hoort het zo te zijn dat je en connectie aanmaakt, records wijzigt en dan db connectie sluiten.

Ik denk dat je een zooitje meer info moet posten voordat we je goed kunnen helpen...

[MueR]

AtlonXP1800 schreef op woensdag 15 juli 2009 @ 14:53:
Om in de toekomst makkelijk uit te kunnen breiden (in het echte script zitten die procedurele regels trouwen niet in de class file er bij)

Dan hoop ik dat die functie die je hier laat zien niet je echte functie is. Over het algemeen wil je een database connectie maar 1 keer maken.

[remco_k]

AtlonXP1800 schreef op woensdag 15 juli 2009 @ 14:53:
[...]
Elke call naar de webservice komt natuurlijk als losse call binnen, maw, elke call instantieert de class, en deze instance wordt dus weer vernietigd aan het einde van de call naar de webservice.
Volgens mij heeft het dan vrij weinig nu iets in de constructor te gaan zetten, want ook dan zal er voor elke call een nieuwe database connectie op worden gezet.

Dan bouw je een 2e class naast die de database handelingen doet en die de connectie éénmalig maakt en die dus ook blijft bestaan. Ook als er geen soap calls zijn.

Wat je nu hebt gemaakt, doet duizenden keren onnodige handshakes en andere shit die totaal overbodig is, en blijkbaar ook je probleem veroorzaken.

[ Voor 10% gewijzigd door remco_k op 15-07-2009 15:29 ]

[Woy]

Ik vraag me ook af hoe de garbage collection van PHP precies werkt, want al staat het inderdaad gewoon zo in de documentatie, lijkt

PHP:

$dbh = null; //verbreek verbinding

Me niet echt netjes om de verbinding te verbreken. Kan het niet zijn dat PHP het object pas later opruimt?

AtlonXP1800 schreef op woensdag 15 juli 2009 @ 15:01:
[...]
mwah, als iemand de database op localhost wil wissen wens ik hem veel succes

Als jij de code die je toont naar buiten toe beschikbaar maakt dan zal dat wel lukken. De code is namenlijk gevoelig voor SQL Injection.

remco_k schreef op woensdag 15 juli 2009 @ 15:28:
[...]

Dan bouw je een 2e class naast die de database handelingen doet en die de connectie éénmalig maakt en die dus ook blijft bestaan. Ook als er geen soap calls zijn.

Wat je nu hebt gemaakt, doet duizenden keren onnodige handshakes en andere shit die totaal overbodig is, en blijkbaar ook je probleem veroorzaken.

Het is in PHP AFAIK niet mogenlijk om objecten in memmory te houden tussen requests door. Misschien zijn er wel andere connection pooling mogenlijkheden in PHP, maar dat weet ik niet.

[ Voor 32% gewijzigd door Woy op 15-07-2009 15:37 ]

[curry684]

AtlonXP1800 schreef op woensdag 15 juli 2009 @ 15:01:
[...]

mwah, als iemand de database op localhost wil wissen wens ik hem veel succes

De meeste databasehacks wissen databases op localhost.

[FragFrog]

Woy schreef op woensdag 15 juli 2009 @ 15:36:
Ik vraag me ook af hoe de garbage collection van PHP precies werkt, want al staat het inderdaad gewoon zo in de documentatie, lijkt

PHP:

$dbh = null; //verbreek verbinding

Me niet echt netjes om de verbinding te verbreken. Kan het niet zijn dat PHP het object pas later opruimt?

Op een gemiddelde LAMP installatie houdt Apache daar gewoon een connectie-pool voor bij, dus maakt het vrij weinig uit. Het gaat pas fout bij concurrente verbindingen, die krijg je doorgaans niet zo snel als je alle updates netjes serieel na elkaar laat lopen.

Het is in PHP AFAIK niet mogenlijk om objecten in memmory te houden tussen requests door. Misschien zijn er wel andere connection pooling mogenlijkheden in PHP, maar dat weet ik niet.

In principe kun je in PHP wel objecten serializen en bijvoorbeeld in een memcache server gooien, maar er staat me bij dat het juist met database connectie objecten niet werkt omdat die resource weer vrijgegeven wordt (aan de connectie pool voor de volgende instance ).

Je enige oplossing is hier ervoor zorgen dat de updates niet te snel na elkaar afgevuurd worden, daar zou je een transactie-log voor bij kunnen gaan houden met een cronjob die continu dat log doorstuurt naar de slave server.

Maar, en dit is een erg grote maar, begin er alsjeblieft niet aan. MySQL is prima in staat zelf replication te regelen op een ongelovelijk veel efficientere manier dan wat jij nu probeert te doen. Daar zit ook een transaction log in zodat je aan de hand daarvan en een daily dump ook nog eens je database kan restoren naar elk gewenst moment (wat geen kwaad kan als je vulnerable bent voor SQL injectie )

[AtlonXP1800]

remco_k schreef op woensdag 15 juli 2009 @ 15:28:
[...]

Dan bouw je een 2e class naast die de database handelingen doet en die de connectie éénmalig maakt en die dus ook blijft bestaan. Ook als er geen soap calls zijn.

Wat je nu hebt gemaakt, doet duizenden keren onnodige handshakes en andere shit die totaal overbodig is, en blijkbaar ook je probleem veroorzaken.

Heb je een voorbeeld? Ik dacht dat PHP stateless was, en je dus niet zo'n connectie open kan houden als het script (in dit geval de webservice) eindigd

gevonden:

code:

$dbh = new PDO($dsn,'username','password', array(PDO::ATTR_PERSISTENT => true));

Aangezien ik geen invloed heb op de aanroepende applicatie kan ik dus alleen per rij de update laten doen. Door PDO te vertellen dat hij een persistent connectie moet aanmaken/gebruiken ben ik van de foutmelding af.

Overigens den ik dat cariolive23 gelijk heeft, dit is niet de ideale manier om het te doen, ook al gaat het maar om 1 tabel. De doorlooptijd is nu 0,015 seconde per record. Op zich niet schokkend, maar je stuurt nogal wat overhead heen en weer natuurlijk.

Ik ga mij eens verdiepen in replication enzo, maar voorlopig kan ik weer even verder

[Woy]

FragFrog schreef op woensdag 15 juli 2009 @ 15:48:
[...]
Op een gemiddelde LAMP installatie houdt Apache daar gewoon een connectie-pool voor bij, dus maakt het vrij weinig uit. Het gaat pas fout bij concurrente verbindingen, die krijg je doorgaans niet zo snel als je alle updates netjes serieel na elkaar laat lopen.

Ok, maar wat ik me afvraag ( maar ik heb geen diepgaande kennis van PHP ) is of PHP wel meteen de connection weer terug geeft aan de connection-pool op het moment dat je een object op null assigned. Kan het niet zo zijn dat de garbage collection ( o.i.d. ) pas later het object opruimt. Met een expliciete close ( dier er voor PDO blijkbaar niet is ) is het veel duidelijker dat je op die plek de resources vrijgeeft.

In principe kun je in PHP wel objecten serializen en bijvoorbeeld in een memcache server gooien, maar er staat me bij dat het juist met database connectie objecten niet werkt omdat die resource weer vrijgegeven wordt (aan de connectie pool voor de volgende instance ).

Het serializen van je connection zal niet helpen, vandaar dat ik ook expliciet "in memory" zei . Een handle naar een database kun je wel bewaren, maar als de daadwerkelijke resource al vrij gegeven is heb je daar niet zo veel meer aan.

Maar, en dit is een erg grote maar, begin er alsjeblieft niet aan. MySQL is prima in staat zelf replication te regelen op een ongelovelijk veel efficientere manier dan wat jij nu probeert te doen. Daar zit ook een transaction log in zodat je aan de hand daarvan en een daily dump ook nog eens je database kan restoren naar elk gewenst moment (wat geen kwaad kan als je vulnerable bent voor SQL injectie )

Dat is sowieso de beste oplossing, je moet niet altijd het wiel opnieuw proberen uit te vinden, als anderen dat allang, waarschijnlijk beter, gedaan hebben.

edit:
het aangeven dat er een persistent connection gebruikt word zal er dan waarschijnlijk in resulteren dat er een connection pool gebruikt word, en dat zal dus het probleem dat je resources opraken inderdaad een stuk voor je uit schuiven.

[ Voor 6% gewijzigd door Woy op 15-07-2009 15:56 ]

[AtlonXP1800]

Woy schreef op woensdag 15 juli 2009 @ 15:36:

[...]

Als jij de code die je toont naar buiten toe beschikbaar maakt dan zal dat wel lukken. De code is namenlijk gevoelig voor SQL Injection.

[...]

Ah, je hebt helemaal gelijk, maar dit draait op een server die alleen intern benaderbaar is, anders had ik wel het e.e.a aan filtering en validatie er in gebouwd

[Woy]

AtlonXP1800 schreef op woensdag 15 juli 2009 @ 15:55:
[...]


Ah, je hebt helemaal gelijk, maar dit draait op een server die alleen intern benaderbaar is, anders had ik wel het e.e.a aan filtering en validatie er in gebouwd

Zelfs op een server die alleen intern beschikbaar is moet je aan filtering doen!!!

[RobIII]

Je moet niet aan "filtering" doen (dan denk althans aan "enge woorden eruit halen") maar gebruik maken van parameterized queries (waar mogelijk) en anders fatsoenlijk escapen.

[FragFrog]

Woy schreef op woensdag 15 juli 2009 @ 15:54:
Ok, maar wat ik me afvraag ( maar ik heb geen diepgaande kennis van PHP ) is of PHP wel meteen de connection weer terug geeft aan de connection-pool op het moment dat je een object op null assigned. Kan het niet zo zijn dat de garbage collection ( o.i.d. ) pas later het object opruimt. Met een expliciete close ( dier er voor PDO blijkbaar niet is ) is het veel duidelijker dat je op die plek de resources vrijgeeft.

Om eerlijk te zijn: ik weet het niet zeker. Sowieso zit er een random component in PHP's GC (die je ook kan instellen), een object op null zetten is genoeg om z'n destructor aan te roepen, maar het zou inderdaad best kunnen dat de connectie pas helemaal op het einde weer vrijgegeven wordt. Nu lijkt het me sowieso niet zo'n goed idee om je eigen server te gaan DoSen, maar deze persistant maken zou al flink kunnen helpen.

RobIII schreef op woensdag 15 juli 2009 @ 16:01:
Je moet niet aan "filtering" doen (dan denk althans aan "enge woorden eruit halen") maar gebruik maken van parameterized queries (waar mogelijk) en anders fatsoenlijk escapen.

Hij gebruikt PDO, dan kun je met prepare inderdaad prima parameterized queries bouwen

[ Voor 18% gewijzigd door FragFrog op 15-07-2009 16:04 ]

[cariolive23]

Het feit dat er geen actie wordt ondernomen tegen SQL-injection, geeft al aan dat de replicatiemethode onbetrouwbaar is. De eerste de beste quote in de content, zal de query laten mislukken en er dus voor zorgen dat er een verschil tussen master en slave ontstaat.

Verder geeft dit wel het niveau van de code aan, beveiling mag nooit en te nimmer ontbreken, het moet een gewoonte zijn. Het moet raar aanvoelen om onveilige code te schrijven. Of moet je ook eerst 3x nadenken voordat je de gordel omdoet wanneer je in de auto stapt?

[Woy]

FragFrog schreef op woensdag 15 juli 2009 @ 16:02:
[...]
Om eerlijk te zijn: ik weet het niet zeker. Sowieso zit er een random component in PHP's GC (die je ook kan instellen), een object op null zetten is genoeg om z'n destructor aan te roepen, maar het zou inderdaad best kunnen dat de connectie pas helemaal op het einde weer vrijgegeven wordt.

Maar garandeerd het op NULL zetten van een object dat de Destructor op dat punt aangeroepen word? Het uit scope laten gaan van het object zorgt er als het goed is ook voor dat het object gedestruct word.

In bijvoorbeeld .NET heb je het disposing pattern, wat er voor zorgt dat objecten resources deterministisch vrij kunnen geven.

In C++ is destructie van locale variabelen zowiezo deterministisch, maar ik vraag me dat bij PHP dus af.

[AtlonXP1800]

cariolive23 schreef op woensdag 15 juli 2009 @ 16:04:
Het feit dat er geen actie wordt ondernomen tegen SQL-injection, geeft al aan dat de replicatiemethode onbetrouwbaar is. De eerste de beste quote in de content, zal de query laten mislukken en er dus voor zorgen dat er een verschil tussen master en slave ontstaat.

Verder geeft dit wel het niveau van de code aan, beveiling mag nooit en te nimmer ontbreken, het moet een gewoonte zijn. Het moet raar aanvoelen om onveilige code te schrijven. Of moet je ook eerst 3x nadenken voordat je de gordel omdoet wanneer je in de auto stapt?

Aangezien ik de code die de request stuurt zelf heb geschreven, en ik er zeker van ben dat die data goed is (het zijn enkel numerieke waarden en er zitten constraints op de database waar ze uit komen) is het nutteloos om nogmaals de data te valideren. (de server die de webservice aanroept is daarnaast de enige die deze kan benaderen)

Wat betreft het voorbeeld van de auto: Als je een auto bouwt zorg je toch eerst dat de motor werkt voordat je de gordels er in doet? Mocht je het willen weten, dit is wat ik er uiteindelijk van zou maken:

code:

$sql = "update table1 set param1  = :p1 where param2 =  :p2 ";      
$stmt = dbh->prepare($sql);
$stmt->bindParam(':p1',$param1);
$stmt->bindParam(':p2',$param2);
$stmt->execute();

[Cartman!]

Maar waarom zou je eerst een brandgevaarlijke motor maken als je ook een veilige motor kunt bouwen als je die kennis blijkbaar hebt of makkelijk kunt opzoeken?

[Voutloos]

AtlonXP1800 schreef op woensdag 15 juli 2009 @ 16:24:
Aangezien ik de code die de request stuurt zelf heb geschreven, en ik er zeker van ben dat die data goed is (het zijn enkel numerieke waarden en er zitten constraints op de database waar ze uit komen) is het nutteloos om nogmaals de data te valideren. (de server die de webservice aanroept is daarnaast de enige die deze kan benaderen)

In deze tekst zit geen enkel valide excuus.

[cariolive23]

Als je een auto bouwt zorg je toch eerst dat de motor werkt voordat je de gordels er in doet?

Voordat er aan een auto wordt gedacht, heeft de motor al vele duizenden uren op de testbank gestaan. Beetje vreemde vergelijking, helemaal omdat men echt geen testrijder de baan opstuurt zonder gordels en zonder helm.

Zo ook met jouw code, je gebruik één veilige methode en die gebruik je netzolang tot je een nog betere methode tot je beschikking hebt. Je gaat geen code slopen (!!!) omdat je per ongeluk teveel vertrouwen hebt in je eigen kunnen. Nergens voor nodig.

[Gomez12]

AtlonXP1800 schreef op woensdag 15 juli 2009 @ 16:24:
[...]


Aangezien ik de code die de request stuurt zelf heb geschreven

Tja, dan lijkt de oplossing me simpel als je het toch via webservices wilt doen, bouw je request class om zodat deze ook bulkmutaties door kan sturen...

Bouw dan gelijk wat error checking in zodat als er foutmeldingen komen dat het request later herhaalt wordt ( net zolang tot er geen fouten meer zijn, let wel even op het zelf dossen van je server )...

Nu is het een beetje dat je een chaos hebt ( foute afhandeling van ontvangen requests ) wat ook nog eens insecure is. Het insecure gedeelte van de chaos wens je blijkbaar wel aan te pakken, maar het echte probleem dat omzeil je enkel maar...

[AtlonXP1800]

Voutloos schreef op woensdag 15 juli 2009 @ 16:48:
[...]
In deze tekst zit geen enkel valide excuus.

Verklaar u nader, want ik zie geen enkele valide reden om aan 2 kanten van lijn een zelfde controle uit te voeren...

[Gomez12]

AtlonXP1800 schreef op woensdag 15 juli 2009 @ 20:22:
[...]

Verklaar u nader, want ik zie geen enkele valide reden om aan 2 kanten van lijn een zelfde controle uit te voeren...

Simpel gezegd, alle data valideren voor opslag.
Kies jij ervoor om het 2x op te slaan, dan ook 2x valideren.

De valide reden is namelijk dat jij niet kan garanderen dat over 2 jaar de dbase enkel door de localhost aangesproken wordt.

Maar imho interessanter geef eens een valide reden waarom je niet aan 2 kanten zou valideren? Desnoods rsync je de validatie classen periodiek over zodat je de validaties maar 1x schrijft.
Nu bouw je gewoon 2 losse projecten op waarbij de ene wel validaties heeft en de andere niet, dat gaat gewoon een keer gigantisch fout.

[Remus]

AtlonXP1800 schreef op woensdag 15 juli 2009 @ 20:22:
[...]

Verklaar u nader, want ik zie geen enkele valide reden om aan 2 kanten van lijn een zelfde controle uit te voeren...

Omdat misschien een kwaadwillende (of een nieuwsgiergie) met bijvoorbeeld Wireshark je verkeer kan sniffen en vervolgens met SoapUI extra of andere calls gaat zitten maken waardoor je data naar de maan is? Dat kan ook intern gebeuren (sterker nog: de kans is groter dat zoiets intern gebeurt).

[ Voor 8% gewijzigd door Remus op 15-07-2009 21:38 ]

[Verwijderd]

Sorry topicstarter, maar geef eerst eens een zinnige reply op het voorstel van cariolive23 om MySQL replicatie op te zetten tussen de MySQL servers. Laat je eigen applicatie even buiten beschouwing en geef één goede reden om géén gebruik te maken van de mogelijkheden die de MySQL server je biedt.

[curry684]

AtlonXP1800 schreef op woensdag 15 juli 2009 @ 20:22:
[...]

Verklaar u nader, want ik zie geen enkele valide reden om aan 2 kanten van lijn een zelfde controle uit te voeren...

Dat hoeft ook niet per definitie, zolang je het maar altijd minimaal aan de ontvangende kant doet. De verzendende kant ook doen is pluspunten voor stijl en betrouwbaarheid. Jij doet het blijkbaar alleen de verzendende kant, da's net zoiets als tegen SQL injection beschermen met een Javascript event die apostrofjes uit inputfields stript. Fancy, maar stupide.

[RobIII]

curry684 schreef op woensdag 15 juli 2009 @ 23:42:
Fancy, maar stupide.

[whoami]

Verwijderd schreef op woensdag 15 juli 2009 @ 21:44:
Sorry topicstarter, maar geef eerst eens een zinnige reply op het voorstel van cariolive23 om MySQL replicatie op te zetten tussen de MySQL servers. Laat je eigen applicatie even buiten beschouwing en geef één goede reden om géén gebruik te maken van de mogelijkheden die de MySQL server je biedt.

Met hem. ^^

Waarom zelf een (brakke / krakkemikkige) 'tool' schrijven, als er blijkbaar al replicatie-functionaliteit in het DBMS ingebakken zit ?
Waarom tijd verliezen in het bouwen van iets dat nooit goed zal werken. (Want, face it, de manier waarop je nu bezig bent is niet goed. Geen parametrized queries, voor iedere query een aparte connectie openen, etc.... Dat 'systeem' gaat op z'n bek gaan. Eerder vroeger dan later).

[AtlonXP1800]

whoami schreef op donderdag 16 juli 2009 @ 00:32:
[...]

Met hem. ^^

Waarom zelf een (brakke / krakkemikkige) 'tool' schrijven, als er blijkbaar al replicatie-functionaliteit in het DBMS ingebakken zit ?
Waarom tijd verliezen in het bouwen van iets dat nooit goed zal werken. (Want, face it, de manier waarop je nu bezig bent is niet goed. Geen parametrized queries, voor iedere query een aparte connectie openen, etc.... Dat 'systeem' gaat op z'n bek gaan. Eerder vroeger dan later).

Zie AtlonXP1800 in "\[PHP/MYSQL] foutmelding bij groot aantal..."

Als je het topic gelezen had, had je gezien dat ik niet meer voor elke query een nieuwe connectie maakt (en zelf het probleem waar dit topic over ging dus al opgelost heb...).

Ik heb inmiddels eens zitten zoeken naar replicatie, van mysql naar mysql kan dat inderdaad erg mooi. Mijn master is een oracle database, daarmee is dat niet zomaar mogelijk. (wel met dure tools)

[ Voor 3% gewijzigd door AtlonXP1800 op 16-07-2009 16:43 ]

[AtlonXP1800]

curry684 schreef op woensdag 15 juli 2009 @ 23:42:
[...]

Dat hoeft ook niet per definitie, zolang je het maar altijd minimaal aan de ontvangende kant doet. De verzendende kant ook doen is pluspunten voor stijl en betrouwbaarheid. Jij doet het blijkbaar alleen de verzendende kant, da's net zoiets als tegen SQL injection beschermen met een Javascript event die apostrofjes uit inputfields stript. Fancy, maar stupide.

Ik ben de enige die de webservice kan benaderen, de webservice draait op een alleen intern benaderbare server, bovendien is die ook nog eens alleen maar benaderbaar vanaf de server die de webservice aanroept. Dus nogmaals, ik zie geen enkel voordeel data te valideren waar je 100% zeker van bent dat die goed is.

[Voutloos]

Puur het nadenken of het nodig is, laat staan het uitleggen dat het niet nodig is @ GoT duurt al vele malen langer dan gewoon desnoods een paar povere int casts.

[cariolive23]

ik zie geen enkel voordeel data te valideren waar je 100% zeker van bent dat die goed is.

Waarom zou je gaan valideren? Je moet gewoon een veilig protocol gebruiken om content in je queries te zetten. Wanneer je dat goed voorelkaar hebt, je hebt daar een goede methode voor, dan ga je toch niet alle beveiliging tegen SQL-injection er weer uit slopen omdat je denkt dat het niet nodig is? Dan krijg je twee verschillende methodes om queries uit te voeren, één veilige en één onveilige methode. Gevolg: vroeg of laat ga je hiermee het schip in. Murphy weet daar alles van.

Hou het simpel, bezorg jezelf geen extra werk en hou het gewoon bij één veilige methode. Wel zo simpel.

Ps. Waarom zou je in hemelsnaam een Oracle-database (zeer goede database) willen repliceren met een MySQL-database (laat ik het voorzichtig zeggen: een bijzonder vaag en onbetrouwbaar geval) ? Er kan veel mis gaan op de slave zonder dat je daar ooit een bericht van krijgt. Wat heb je dan nog aan de slave? Niets...

[curry684]

AtlonXP1800 schreef op donderdag 16 juli 2009 @ 16:47:
[...]


Ik ben de enige die de webservice kan benaderen, de webservice draait op een alleen intern benaderbare server, bovendien is die ook nog eens alleen maar benaderbaar vanaf de server die de webservice aanroept. Dus nogmaals, ik zie geen enkel voordeel data te valideren waar je 100% zeker van bent dat die goed is.

Je kent overduidelijk regel 1 van programmeren nog niet. Hij is heel simpel en telt maar 3 woorden:

NEVER
TRUST
INPUT

Leuk dat je webserver alleen maar intern benaderbaar is, en alleen benaderbaar is vanaf de server die de webservice aanroept. Een aantal van de volgende scenario's gaan met grote waarschijnlijkheid de komende jaren plaatsvinden:

• De aanroepende server wordt vervangen door een nieuwe. De systeembeheerder heeft geen documentatie of hem niet gelezen, en vergeet dus het IP-filter in te stellen.
• De interne IP's worden veranderd. Iemand merkt dat jouw systeem niet meer werkt door een IP-filter en haalt hem maar weg omdat ie alleen maar in de weg zit.
• De ontvangende server gaat ook andere websites zoals de publieke bedrijfssite, testsites of een extranet draaien, en wordt dus aan internet gekoppeld. Het IP-filter wordt weggehaald omdat ie wel vanaf internet benaderd moet worden.
• Een rancuneuze medewerker wiens contract niet verlengd wordt kent toevallig de stommiteiten in jouw systeem en gooit voor de lol jouw DB weg in z'n uitwerkperiode.
• etc. etc. etc.

Een echte programmeur programmeert altijd defensief. Je neemt geen aannames dat de wereld rooskleurig is, dat firewalls en servers goed geconfigureerd zijn en blijven, en dat kabeltjes die er nu niet liggen over een jaar nog steeds niet liggen.

De ENIGE aanname die je ooit als programmeur ongefundeerd mag maken is dat iedereen op de hele wereld er full time onafgebroken op uit is om jouw programmatuur te slopen.

[Verwijderd]

Waarom gebruik je niet gewoon database replication voor het synchroon houden van je databases?

[whoami]

AtlonXP1800 schreef op donderdag 16 juli 2009 @ 16:47:
[...]


Ik ben de enige die de webservice kan benaderen, de webservice draait op een alleen intern benaderbare server, bovendien is die ook nog eens alleen maar benaderbaar vanaf de server die de webservice aanroept.

Waarom heb je dan een WS nodig ?

Dus nogmaals, ik zie geen enkel voordeel data te valideren waar je 100% zeker van bent dat die goed is.

Wie zegt dat er nooit eens iemand zichzelf toegang verschaft tot die WS ?
Wie zegt dat jij nooit per ongeluk niet valide data input ?

Tja, waarom m'n autogordel om doen, ik rij altijd veilig