h oxid server should have a local
running postfix server that acts as a local mail queue. That way the shop
can always send a email even if the network is down.
best regards
K1
[Your secret expert for high security, availablity and performance.]
From: "Marco Steinhaeuser"
Date: Mo
einhaeu...@oxid-esales.com>>
Date: Mon, Nov 27, 2017 at 6:06 PM +0100
Subject: Re: Re-2: oxid V6 MySQL transactions
To: "dev-general@lists.oxidforge.org
<mailto:dev-general@lists.oxidforge.org>"
mailto:dev-general@lists.oxidforge.org&g
quot;Marco Steinhaeuser"
Date: Mon, Nov 27, 2017 at 6:06 PM +0100
Subject: Re: Re-2: oxid V6 MySQL transactions
To: "dev-general@lists.oxidforge.org"
Folks,
could we please stick to English in this channel?
Cheers!
Marco
Ursprüngliche Nachricht
Von: Robert
Folks,
could we please stick to English in this channel?
Cheers!
Marco
Ursprüngliche Nachricht
Von: Robert Blank
Datum: 27.11.17 17:54 (GMT+01:00)
An: dev-general@lists.oxidforge.org
Betreff: Re: Re-2: oxid V6 MySQL transactions
Hallo,
Man kann in Doctrine leider das
Hallo,
Man kann in Doctrine leider das Rollback in verschachtelten
Transaktionen nicht feinkörnig steuern, bzw kapseln: Wenn eine der
inneren Transaktionen einen rollback macht, werden alle daran
beteiligten Transaktionen (auch die äußeren!) zurück gerollt.
http://docs.doctrine-project.org/p
Hallo,
die Antwort ist für mich wirklich schwer zu akzeptieren.
"We want really all database transactions to be rolled back, if a problem
during e.g. the payment execution occurs."
Es passiert eine payment transaktion! Wie soll auf so ein Fall korrekt reagiert
werden?
Beispiel: Eine Bestell
