|
Björn [email protected]
|
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 [email protected]
|
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/
|
