Normally for OLAP workflows you want your updates to either be idempotent or be tagged with an id that identifies the ETL job they generated then (very helpful for auditing and related functions), or have a kind of "build and swap" model to ensure availability. That, and performance concerns, mean a lot of OLAP servers consequently often have very limited support for transactions.
We ran into enough issues with partial writes during rollbacks due to failed transactions that we eventually had to abandon it in favor of Infobright. Having said that queries were ridiculously fast for OLAP workflows involving millions of records.