Folks,

could we please stick to English in this channel?

Cheers!
Marco



-------- Ursprüngliche Nachricht --------
Von: Robert Blank <robert.bl...@oxid-esales.com>
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 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/projects/doctrine-dbal/en/latest/reference/transactions.html#transaction-nesting

"To achieve that, you need to restructure your application logic so as to avoid 
nesting transaction blocks. If this is not possible because the nested 
transaction blocks are in a third-party API you’re out of luck."

Da liegt m.E. der Pudels Kern. Durch das Modulsystem haben wir sozusagen diesen 
Fall der "third-party API", denn jedes Modul kann ja theoretisch ein 
->rollbackTransaction() aufrufen und damit sind dann sowieso alle Möglichkeiten 
hinüber. Es wird ausdrücklich darauf hingewiesen nicht anzufangen kreativ zu 
programmieren:
Directly invoking PDO#beginTransaction(), PDO#commit() or PDO#rollBack() or the 
corresponding methods on the particular Doctrine\DBAL\Driver\Connection 
instance in use bypasses the transparent transaction nesting that is provided 
by Doctrine\DBAL\Connection and can therefore corrupt the nesting level, 
causing errors with broken transaction boundaries that may be hard to debug.
Das Rollback lässt sich ab diesem Moment nicht mehr überschreiben.

Die einzige Garantie die das Framework hier geben kann und will ist "all or 
nothing".

MfG

Robert Blank


P.S.

"Zumal es völlig sinnfrei ist, eine Bestellung nur wegen einer nicht 
verschickbaren Mail komplett zu verwerfen."
(+1)

On 27.11.2017 16:34, oxid mailinglist wrote:
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 Bestellung ist komplett durchgeführt inkl erfolgreiche Bezahlung 
per Paymentanbieter. Nun kann jedoch die Mail an den Kunden nicht geschickt 
werden. Es erfolgt ein komplettes rollback!

Wie soll nun ein Paymentmodul korrekt darauf reagieren können? Es gibt keine 
transaktionslog-Infos mehr.
Zumal es völlig sinnfrei ist, eine Bestellung nur wegen einer nicht 
verschickbaren Mail komplett zu verwerfen. Aber darum geht es gar nicht.

Es gibt aktuell keine Möglichkeit auf ein rollback korrekt zu reagieren, da 
nicht überladbar.
->  \OxidEsales\Eshop\Core\DatabaseProvider::getDb()->startTransaction();

Es muss doch von OXID eine Möglichkeit geben auf so ein Ereignis korrekt 
reagieren zu können, ohne dass man die eigenen log/transaktions-Daten in 
Dateien abspeichern muss!


Mit freundlichen Grüßen
Thomas Dartsch
thomas.dart...@shopmodule.com<mailto:thomas.dart...@shopmodule.com>


 Original Message processed by david®



Re: oxid V6 MySQL transactions (27-Nov-2017 16:00)

From:   Robert Blank<mailto:robert.bl...@oxid-esales.com>

To:
        dev-general@lists.oxidforge.org<mailto:dev-general@lists.oxidforge.org>


Hi,

in your use-case this may sound strange, but this is by design.
First by OXID eShop design:
We want really _all_ database transactions to be rolled back, if a problem 
during e.g. the payment execution occurs.

Then there is the design of the underlying DBAL:
As we us Doctrine DBAL, we cannot provide savepoints or partial rollbacks, as 
Doctrine DBAL does not provide this functionality:
http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/transactions.html#transaction-nesting

You should also not try to bypass this behavior as it will break the nested 
transaction handling of Doctrine.
In you case I fear, there is no other way as to store your log data into a file.

Best regards


Robert Blank


On 20.11.2017 15:13, oxid mailinglist wrote:

Hello guys,

with oxid Version 6.0 the shop is using MySQL transactions. -> 
https://dev.mysql.com/doc/refman/5.7/en/commit.html

For example this is used in 
OxidEsales\Eshop\Application\Model\Order::recalculateOrder
(formally known as oxorder::recalculateOrder).
https://github.com/OXID-eSales/oxideshop_ce/blob/472ce3d73e5f0e46a29566f5290a85d631bd00db/source/Application/Model/Order.php#L1354

In the process of Order::finalizeOrder, the PaymentGateway::executePayment() 
allows
modules to perform module based validations.
https://github.com/OXID-eSales/oxideshop_ce/blob/472ce3d73e5f0e46a29566f5290a85d631bd00db/source/Application/Model/Order.php#L916

Some payment provider will create transactions and send it back to the shop.
A module will be willing to save/log these transactions to the database.
If there are a failed transaction and the module save his object via shop 
standard BaseModel::save()
and the PaymentGateway::executePayment() return a false,
the complete MySQL transaction will be ROLLBACK'ed. (Order::recalculateOrder())
https://github.com/OXID-eSales/oxideshop_ce/blob/472ce3d73e5f0e46a29566f5290a85d631bd00db/source/Application/Model/Order.php#L1374

So the module lost all informations/transactions, which are saved during the 
transaction.


How is oxid's suggestion to save these transactions from ROLLBACK?



best regards
Kristian Hempel

--


Richten Sie Fehlermeldungen und Supportanfragen bitte an 
supp...@shopmodule.com<mailto:supp...@shopmodule.com>.
________________________________
        Fresh ideas for your business
________________________________

D³ Data Development (Inh. Thomas Dartsch)
Stollberger Straße 23 · D-09380 Thalheim
Fon 03721 268090 · Fax 03721 265234

Shop:   http://www.oxidmodule.com<http://www.oxidmodule.com/>   Firma:  
http://www.shopmodule.com<http://www.shopmodule.com/>
Blog:   http://blog.oxidmodule.com<http://blog.oxidmodule.com/>         FAQ:    
http://faq.oxidmodule.com<http://faq.oxidmodule.com/>
[http://www.oxidmodule.com/email/oxid_business_level.png]       OXID eSales AG
Certified Partner
Business Level
        [http://www.oxidmodule.com/email/profihost_enterprise_partner.png]      
Profihost AG
Enterprise Partner


--


Robert Blank
Software Developer OXID Platform

robert.bl...@oxid-esales.com<mailto:robert.bl...@oxid-esales.com>
Fon +49 761 36889-233
Fax +49 761 36889-29
www.oxid-esales.com<http://www.oxid-esales.com?campaign=emailsignatur/oxid-esales-com&adword=OXSIG_Startseite>


OXID eSales AG
Bertoldstraße 48
79098 Freiburg
Deutschland

Vorstand: Roland Fesenmayr (Vorsitzender), Dr. Oliver Ciupke
Vorsitzender des Aufsichtsrats: Michael Schlenk, Sitz: Freiburg
Amtsgericht Freiburg i. Br., HRB 701648, USt-IdNr.: DE231450866




--


Robert Blank
Software Developer OXID Platform

robert.bl...@oxid-esales.com<mailto:robert.bl...@oxid-esales.com>
Fon +49 761 36889-233
Fax +49 761 36889-29
www.oxid-esales.com<http://www.oxid-esales.com?campaign=emailsignatur/oxid-esales-com&adword=OXSIG_Startseite>


OXID eSales AG
Bertoldstraße 48
79098 Freiburg
Deutschland

Vorstand: Roland Fesenmayr (Vorsitzender), Dr. Oliver Ciupke
Vorsitzender des Aufsichtsrats: Michael Schlenk, Sitz: Freiburg
Amtsgericht Freiburg i. Br., HRB 701648, USt-IdNr.: DE231450866


Reply via email to