EF-Transaktionen nicht korrekt
- Ersteller seppl2000
- Erstellt am
- 20 April 2006
- 22.680
- 1.315
Ja. Aber nicht kontrollieren, was sich auf dem Server abspieltÜber dem Browser kann man den Ladevorgang abbrechen...
Er kann die Verbindung abbrechen, die er zu dir aufgebaut. Du kontrollierst aber, was auf dem Server läuft und wann da was abgebrochen wird.
Auf dem Server spielte sich das so ab, das ich über meinen EF 65mrd. in 3 Fehlbuchungen an einen User gesendet habe, ohne das bei mir auf der Seite Guthaben abgezogen wurde oder Statistiken geschrieben wurden.
Und das passiert anscheinend, wenn ein Server mal zu lange hakt und der User über den "Browser" den Ladevorgang abbricht. Die Lose kommen beim User an und auf meiner Seite passiert garnix und der User kann nochmal alles auszahlen, falls es wieder hakt auch ein 3. mal.
Edit: Jetzt ist es nicht mehr so da ich nun zuerst eine Stat+Buchung habe zum kontrollieren, welche vorher geschrieben & gebucht wird auf meiner Seite und notfalls retour falls was hakt. Aber so kann man mit der Api-Schnittstelle keine Sicherheit gewähren für die Betreiber nach der verfügbaren Beschreibung zu proggen.
Seriöse Betreiber senden Guthaben jederzeit nach, wenn die Lose dazu auf den EF kommen oder falls welche nicht auf Klamm ankommen bei einer Auszahlung. Nur umgekehrt müssen alle Betreiber jegliche Transaktionen mit denen in ihrer Statistik mühsam vergleichen um Fehler auszuschließen.
Aber bevor es hier ausartet in Diskussionen, wo ich als Grafiker/Webmaster eh nicht mit dem Knowhow glänzen kann wie manch einer, kümmere ich mich lieber drum das bei mir wenigstens alles nachvollziehbar bleibt auch wenn Server haken.
Und das passiert anscheinend, wenn ein Server mal zu lange hakt und der User über den "Browser" den Ladevorgang abbricht. Die Lose kommen beim User an und auf meiner Seite passiert garnix und der User kann nochmal alles auszahlen, falls es wieder hakt auch ein 3. mal.
Edit: Jetzt ist es nicht mehr so da ich nun zuerst eine Stat+Buchung habe zum kontrollieren, welche vorher geschrieben & gebucht wird auf meiner Seite und notfalls retour falls was hakt. Aber so kann man mit der Api-Schnittstelle keine Sicherheit gewähren für die Betreiber nach der verfügbaren Beschreibung zu proggen.
Seriöse Betreiber senden Guthaben jederzeit nach, wenn die Lose dazu auf den EF kommen oder falls welche nicht auf Klamm ankommen bei einer Auszahlung. Nur umgekehrt müssen alle Betreiber jegliche Transaktionen mit denen in ihrer Statistik mühsam vergleichen um Fehler auszuschließen.
Aber bevor es hier ausartet in Diskussionen, wo ich als Grafiker/Webmaster eh nicht mit dem Knowhow glänzen kann wie manch einer, kümmere ich mich lieber drum das bei mir wenigstens alles nachvollziehbar bleibt auch wenn Server haken.
Zuletzt bearbeitet:
tobias1985
Der Erlöser
- 24 April 2006
- 4.963
- 607
Deshalb verbucht man die Auszahlung auch erst intern und schickt dann die Lose an den User. Und wenn das schief läuft, bucht man die Lose wieder drauf.
Und beim Einzahlen holt man sich erst die Lose vom klamm-Account und verbucht dann intern. Problem hierbei ist eben das, was die letzten 2 Wochen des öfteren aufgetreten ist. Klamm hängt, bucht dann aber doch noch die Lose um. Das Script hat aber schon abgebrochen und die Lose wurden intern nicht verbucht.
Dann bekommt man Support-Tickets über fehlende Einzahlungen.
Oder man implementiert eben EF-Confirm mit der der User Transaktionen prüfen kann. So ist es bei superslots zum Beispiel gemacht.
Ich verzichte auf EF-Confirm. Kostet entweder unnötig EF-Anfragen oder der User versteht die Funktion nicht, je nach Realisierung. Also lass ich es gleich sein und bearbeite weiterhin Support-Tickets.
Im übrigen waren das die ersten solcher Probleme, die ich seit ca. 1 1/2 Jahren EF-Nutzung hatte.
EDIT: Superslots hats nur für Auszahlungen implementiert. Dürfte also bei Einzahlungen die gleichen Probleme bekommen. Es sei denn, da läuft ein Script das die EF-Transaktionen mit den internen Buchungen abgleicht...
Und beim Einzahlen holt man sich erst die Lose vom klamm-Account und verbucht dann intern. Problem hierbei ist eben das, was die letzten 2 Wochen des öfteren aufgetreten ist. Klamm hängt, bucht dann aber doch noch die Lose um. Das Script hat aber schon abgebrochen und die Lose wurden intern nicht verbucht.
Dann bekommt man Support-Tickets über fehlende Einzahlungen.
Oder man implementiert eben EF-Confirm mit der der User Transaktionen prüfen kann. So ist es bei superslots zum Beispiel gemacht.
Ich verzichte auf EF-Confirm. Kostet entweder unnötig EF-Anfragen oder der User versteht die Funktion nicht, je nach Realisierung. Also lass ich es gleich sein und bearbeite weiterhin Support-Tickets.
Im übrigen waren das die ersten solcher Probleme, die ich seit ca. 1 1/2 Jahren EF-Nutzung hatte.
EDIT: Superslots hats nur für Auszahlungen implementiert. Dürfte also bei Einzahlungen die gleichen Probleme bekommen. Es sei denn, da läuft ein Script das die EF-Transaktionen mit den internen Buchungen abgleicht...
genau so wurde es jetzt auch geändert. wobei 1. die API Beschreibung auch überarbeitet gehört den aktuell sieht die eben nicht so aus. und zusätzlich bügelst du dadurch nur den fehler der API aus. aber wirklich schön ist die Lösung nicht. Aber gut mir könnte es ja eigentlich egal sein da ich eh keine Loseauszahlung bei meinen Projekten mache zumindest keine autom. nur wurde ich nun mal von Deax gebeten mir das anzuschauen. Und dachte mir okay ich erkläre mal das problem etwas besser damit es verstanden wird damit man die api verbessern könnte. mir ist egal wie es gemacht wird. Es ist nicht mein Ruf der darunter leidet.
Auf meiner Seite nutze ich EF-Confirm, und es verbraucht extrem wenig Anfragen.
User will einzahlen: ich trage die geplante Transaktion in eine extra Tabelle (die Comfirm-Tabelle) ein. Dann ziehe ich per ef_get die Lose auf den EF. Wenn die API 1001 sagt (alles OK), dann bekommt der User die Lose auch gutgeschrieben (und der Eintrag in der confirm-Tabelle wird gelöscht). Sagt die API nichts (also timeout), bekommt der User einen extra Link angezeigt zum Prüfen der Transaktion. In diesem Fall wird der Eintrag aus der Confirm-Tabelle genutzt und ein ef_confirm ausgeführt. Ggf. werden also dem User nachträglich die Lose gutgeschrieben.
Bei der Auszahlung geht das alles etwas anders: Eintrag in die Confirm-Tabelle, Verringern des Userkontostandes auf der Seite, API-Aufruf zum Auszahlen. In der Reihenfolge. Wenn die API 1001 antwortet, muss ich nur noch den Eintrag in der Confirm-Tabelle löschen. Wenn es einen timeout gibt, bekommt der User wieder einen extra Link angezeigt, mit dem er die Transaktion prüfen kann. Falls die Lose wirklich nicht ausgezahlt wurden, schreibt das Script sie dem User auch wieder gut. Wenn die Lose doch ausgezahlt wurden, muss nur der Eintrag in der Confirm-Tabelle gelöscht werden.
In allen Fällen habe ich keinen Verlust durch Doppel- oder Falschbuchungen. Der User kann aktiv die Buchungen prüfen und bekommt in jedem Fall die Lose korrekt gutgeschrieben oder abgezogen, auch die EF-Transaktionen passen zu den internen Buchungen.
Ich verbrauche Confirm-Aufrufe also nur dann, wenn es einen timeout gab und wenn der User deshalb den entsprechenden Prüflink klickt. Und das kann er nur, wenn es einen Eintrag in meiner Confirm-Tabelle gibt.
Deshalb musst du bei Auszahlungen eben erst den Userkontostand verringern. Dann kann ein User nicht mehrmals auszahlen. Wenn die API nicht erreichbar war, kann man ja später, wenn sie es doch wieder ist, die Sache korrigieren.
Programmieren oder Scripte entwickeln ist eben nicht nur Code einhacken, sondern sich auch Algorithmen überlegen (und umsetzen).
User will einzahlen: ich trage die geplante Transaktion in eine extra Tabelle (die Comfirm-Tabelle) ein. Dann ziehe ich per ef_get die Lose auf den EF. Wenn die API 1001 sagt (alles OK), dann bekommt der User die Lose auch gutgeschrieben (und der Eintrag in der confirm-Tabelle wird gelöscht). Sagt die API nichts (also timeout), bekommt der User einen extra Link angezeigt zum Prüfen der Transaktion. In diesem Fall wird der Eintrag aus der Confirm-Tabelle genutzt und ein ef_confirm ausgeführt. Ggf. werden also dem User nachträglich die Lose gutgeschrieben.
Bei der Auszahlung geht das alles etwas anders: Eintrag in die Confirm-Tabelle, Verringern des Userkontostandes auf der Seite, API-Aufruf zum Auszahlen. In der Reihenfolge. Wenn die API 1001 antwortet, muss ich nur noch den Eintrag in der Confirm-Tabelle löschen. Wenn es einen timeout gibt, bekommt der User wieder einen extra Link angezeigt, mit dem er die Transaktion prüfen kann. Falls die Lose wirklich nicht ausgezahlt wurden, schreibt das Script sie dem User auch wieder gut. Wenn die Lose doch ausgezahlt wurden, muss nur der Eintrag in der Confirm-Tabelle gelöscht werden.
In allen Fällen habe ich keinen Verlust durch Doppel- oder Falschbuchungen. Der User kann aktiv die Buchungen prüfen und bekommt in jedem Fall die Lose korrekt gutgeschrieben oder abgezogen, auch die EF-Transaktionen passen zu den internen Buchungen.
Ich verbrauche Confirm-Aufrufe also nur dann, wenn es einen timeout gab und wenn der User deshalb den entsprechenden Prüflink klickt. Und das kann er nur, wenn es einen Eintrag in meiner Confirm-Tabelle gibt.
Deshalb musst du bei Auszahlungen eben erst den Userkontostand verringern. Dann kann ein User nicht mehrmals auszahlen. Wenn die API nicht erreichbar war, kann man ja später, wenn sie es doch wieder ist, die Sache korrigieren.
Programmieren oder Scripte entwickeln ist eben nicht nur Code einhacken, sondern sich auch Algorithmen überlegen (und umsetzen)
.Sorry find die aussage schon bissel frech ich habe eure API ja nicht so bescheuert Programmiert. Ich glaub das wart doch Ihr ich hab lediglich ne Schnittstelle dazu gemacht und sorry aber wenn eure eigene code beispiele für die Katz sind schiebt es bitte auch nicht auf andere. bei anderen API Schnittstellen läuft auch alles ohne probleme wie Sofortüberweisung / Paypal usw.
hinzugefügt:
Achso und wenn die API nicht erreichbar wird wird auch nichts abgezogen wie den auch dafür ist eine Prüfung vorhanden. Nur von wegen guthaben abziehen dann erst mal schauen ob der user per api überhaupt existiert und gegebenfalls wieder gutschreiben das ist müll nicht mehr nicht weniger.
hinzugefügt:
Achso und wenn die API nicht erreichbar wird wird auch nichts abgezogen wie den auch dafür ist eine Prüfung vorhanden. Nur von wegen guthaben abziehen dann erst mal schauen ob der user per api überhaupt existiert und gegebenfalls wieder gutschreiben das ist müll nicht mehr nicht weniger.
Wen meinst du mit "ihr"? Ich bin auch nur Anwender. Ich habe keinen Zugriff auf den API-Code oder auf irgendeinen klamm-Server. Und bescheuert finde ich das eben nicht. Ich habe dir nur aufgezeigt, dass man mit der bestimmungsgemäßen Nutzung der API-Funktionen "Verluste", wie du sie beklagt hast, vermeiden kann.
Stimmt, es gibt kein komplettes vorgegebenes framework, wir man die API nutzen kann. Man muss sich selbst überlegen, welche Funktion man an welcher Stelle wie einsetzt. Das sehe ich aber nicht unbedingt als Nachteil an. Wer die Funktionen benutzen will, braucht Grundwissen und "hackt" nicht nur Code zusammen, den man nicht versteht. OK, manche Leute machen das eben doch (und damit meine ich nicht dich, also nicht gleich ausrasten ), aber dann muss man sich auch nicht wundern, wenn es Probleme gibt.
Stimmt, es gibt kein komplettes vorgegebenes framework, wir man die API nutzen kann. Man muss sich selbst überlegen, welche Funktion man an welcher Stelle wie einsetzt. Das sehe ich aber nicht unbedingt als Nachteil an. Wer die Funktionen benutzen will, braucht Grundwissen und "hackt" nicht nur Code zusammen, den man nicht versteht. OK, manche Leute machen das eben doch (und damit meine ich nicht dich, also nicht gleich ausrasten
), aber dann muss man sich auch nicht wundern, wenn es Probleme gibt.Was meinst du mit "sauberer Lösung"? Ich habe den Algorithmus aufgeschrieben, wie man verlustfrei (für User und Seitenbetreiber) die API nutzen kann. Es gibt nur zeitweise (also für die Zeit des timeouts) Differenzen in seiteninternen und EF-Buchungen, die aber sofort behoben werden können, wenn die API wieder erreichbar ist. Noch sauberer geht es doch kaum. Es sind nun mal mehrere Schritte über mehrere Datenbanken auszuführen, und da gibt es kein globales rollback.
- 20 April 2006
- 22.680
- 1.315
Sieht mir eher so aus, als ob die Loseseiten nicht sauber programmiert sind, wenn sie bei so einer Kleinigkeit wie einem Timeout gleich versagen
Im Internet kanns immer mal einen Timeout geben oder einen Server, der nicht erreichbar is, egal, ob du jetzt klamm's EF oder PayPal am anderen Ende der Leitung hast. Das muss nicht unbedingt der Zielserver selber sein. Auch ein Router auf dem Weg zum Ziel kann mal defekt sein und du erreichst die Gegenstelle deshalb nicht.
Du musst so oder so mit einem Fehlerfall rechnen und ihn korrekt abfangen.
Tust du das nicht, bist du derjenige, der bescheuert programmiert hat, um dich mal so liebevoll zu zitieren
Eine API is nicht für Errorhandling zuständig. Das is derjenige, der sie anspricht.kommt vergisst es. ich habe ne saubere sichere variante aufgezeigt um eventl. zu helfen die API zu verbessern aber scheint ja anscheinend nicht wirklich interesse da zu sein um etwas zu verbessern. mir ist egal ist eure kiste nicht meine. bin dann mal weg.
DelphiKing
King with a crown
- 20 April 2006
- 6.554
- 729
Offenbar hast du weder verstanden, wie die EF-API funktioniert, noch was Mone über die sinnvolle Implementierung der Confirm-Methode geschrieben hat…
Aber hauptsache pampig werden wenn jemand versucht, dir das zu erklären, oder?
tobias1985
Der Erlöser
- 24 April 2006
- 4.963
- 607
Die Lösung von Mone war auch die, die ich in Erwägung gezogen hatte. Aber meine Befürchtung dazu ist, dass die User das nicht verstehen bzw. die Möglichkeit erst gar nicht verwenden sondern doch Support-Tickets schreiben. Gibt es dazu Erfahrungswerte? (@Mone)
@tobias1985, umsatzmäßig komme ich an deine Zahlen sicher nicht ran .
Ganz konkret sieht das bei mir so aus:
Der Link wird also immer angezeigt, aber nur wenn es solche timeout-Buchungen gab, sieht man auch was auf der dahinterliegenden Seite. Sonst sieht das so aus:
Ich dachte mir, dass die User so einfach wissen, dass es die Möglichkeit der Selbstprüfung gibt und die dann hoffentlich auch nutzen.
Genau genommen gab es bei mir überhaupt noch keine Usermeldung wegen fehlerhafter Buchung. Ich logge aber auch nicht mit, wie oft das auftritt.
Und selbst wenn einzelne User das nicht verstehen: die, die es verstehen, schreiben keine Supportnachricht mehr, also würde die Umsetzung doch schon was helfen.
.Ganz konkret sieht das bei mir so aus:
Der Link wird also immer angezeigt, aber nur wenn es solche timeout-Buchungen gab, sieht man auch was auf der dahinterliegenden Seite. Sonst sieht das so aus:
Ich dachte mir, dass die User so einfach wissen, dass es die Möglichkeit der Selbstprüfung gibt und die dann hoffentlich auch nutzen.
Genau genommen gab es bei mir überhaupt noch keine Usermeldung wegen fehlerhafter Buchung. Ich logge aber auch nicht mit, wie oft das auftritt.
Und selbst wenn einzelne User das nicht verstehen: die, die es verstehen, schreiben keine Supportnachricht mehr, also würde die Umsetzung doch schon was helfen.