Why is DB transaction failure considered a fatal error?

Author Message

Piotrek Karaś

Thursday 07 August 2008 7:32:06 am

This has bugged me for some time: why are DB transaction failures considered fatal error in eZ Publish?

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu

Björn Dieding@xrow.de

Thursday 07 August 2008 11:40:35 am

I would explain it like this:

When a transaction fails something does terribily wrong. Instead of breaking the data/system even more if we would continue we better stop right here.

Though it should at least give some nicer html wihtout producing any more queries to the database.

Looking for a new job? http://www.xrow.com/xrow-GmbH/Jobs
Looking for hosting? http://hostingezpublish.com
-----------------------------------------------------------------------------
GMT +01:00 Hannover, Germany
Web: http://www.xrow.com/

Piotrek Karaś

Thursday 07 August 2008 12:11:43 pm

Hi Björn,

Thanks for the reply. Yup, that would be my guess. Especially for an application that has strong PHP4 roots and default application-side DB consistency and constraint control.

However, the way I understand transactions, they're meant to prevent non-consistent multi-query operations, but whether a transaction goes thought or not is - from db point of view - equal to any query going though actually. If one non-transaction query of a hundred of queries, some of which belong to transactions, fails, it may be equally disastrous for the application if it goes undetected (think of timeouts, for example). Shouldn't then risky operations in apps such as eZ be covered with one big transaction (we would then rely on DB's rollback to have more chances of not leaving the DB in an inconsistent shape)?

I'm asking this because it seems to me that in some apps transactions are used to attempt to secure serializable (or whatever isolation level) operation consistency, and if that fails, well, then it just fails and proper exception or error is caught, so that decisions can be made how to deal further (for example, display feedback in UI). It may be the case for DBs that handle business logic only, I'm not sure (while we have all the layers somehow mixed in eZ).

Still, I occasionally catch myself using this approach, and forgetting that if transaction fails in eZ Publish, well, user will experience fatal error ;(

If I miss or misunderstand something, I'd be happy to learn.

Thanks,
Piotrek

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu

Björn Dieding@xrow.de

Thursday 07 August 2008 7:04:09 pm

Hi,

consider each db vendor has their own implementation about transactions and more advanced features. What we use in eZ Publish is the least common feature set to make it run on as many dbs as possible. Mysql it not that feature rich itself. Other vendor have more possibilities in making your data protected.

Just consider again... if you see transaction errors something is really wrong. You do not see them with a stable site. So we shouldn't bother and try to fix something afterwards that went wrong in the first place. It makes no sense to invest time in something that is so rarly seen and mostly working great.

Looking for a new job? http://www.xrow.com/xrow-GmbH/Jobs
Looking for hosting? http://hostingezpublish.com
-----------------------------------------------------------------------------
GMT +01:00 Hannover, Germany
Web: http://www.xrow.com/

Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2014 eZ Systems AS (except where otherwise noted). All rights reserved.

eZ debug

Timing: Jan 18 2025 20:54:02
Script start
Timing: Jan 18 2025 20:54:02
Module start 'layout'
Timing: Jan 18 2025 20:54:02
Module start 'content'
Timing: Jan 18 2025 20:54:03
Module end 'content'
Timing: Jan 18 2025 20:54:03
Script end

Main resources:

Total runtime0.6796 sec
Peak memory usage4,096.0000 KB
Database Queries60

Timing points:

CheckpointStart (sec)Duration (sec)Memory at start (KB)Memory used (KB)
Script start 0.00000.0063 588.1563152.6563
Module start 'layout' 0.00630.0029 740.812539.4922
Module start 'content' 0.00920.6687 780.3047561.9063
Module end 'content' 0.67790.0016 1,342.210916.1250
Script end 0.6795  1,358.3359 

Time accumulators:

 Accumulator Duration (sec) Duration (%) Count Average (sec)
Ini load
Load cache0.00350.5142160.0002
Check MTime0.00150.2141160.0001
Mysql Total
Database connection0.00080.117310.0008
Mysqli_queries0.614290.3844600.0102
Looping result0.00060.0943580.0000
Template Total0.637593.820.3187
Template load0.00220.323020.0011
Template processing0.635393.478520.3176
Template load and register function0.00010.022110.0001
states
state_id_array0.00100.150810.0010
state_identifier_array0.00190.278420.0009
Override
Cache load0.00180.2691250.0001
Sytem overhead
Fetch class attribute can translate value0.00070.102420.0003
Fetch class attribute name0.00110.166760.0002
XML
Image XML parsing0.00450.663220.0023
class_abstraction
Instantiating content class attribute0.00000.002780.0000
General
dbfile0.00781.1544230.0003
String conversion0.00000.000940.0000
Note: percentages do not add up to 100% because some accumulators overlap

Templates used to render the page:

UsageRequested templateTemplateTemplate loadedEditOverride
1node/view/full.tplfull/forum_topic.tplextension/sevenx/design/simple/override/templates/full/forum_topic.tplEdit templateOverride template
4content/datatype/view/ezimage.tpl<No override>extension/sevenx/design/simple/templates/content/datatype/view/ezimage.tplEdit templateOverride template
4content/datatype/view/ezxmltext.tpl<No override>extension/community_design/design/suncana/templates/content/datatype/view/ezxmltext.tplEdit templateOverride template
5content/datatype/view/ezxmltags/paragraph.tpl<No override>extension/ezwebin/design/ezwebin/templates/content/datatype/view/ezxmltags/paragraph.tplEdit templateOverride template
1content/datatype/view/ezxmltags/line.tpl<No override>design/standard/templates/content/datatype/view/ezxmltags/line.tplEdit templateOverride template
1print_pagelayout.tpl<No override>extension/community/design/community/templates/print_pagelayout.tplEdit templateOverride template
 Number of times templates used: 16
 Number of unique templates used: 6

Time used to render debug report: 0.0001 secs