Is dirty-read a problem in an always-commit database? Is this statement true:


  If a DB engine disallows rollback and always uses a redo log to enforce commits, then dirty-reads never happen (because all changes will be commited finally).


If so, are there any use cases where dirty reads can be avoided by disallowing rollback?

The only obstacle I can think of is for a transaction to violate some constraints so that commits always fail. But there may be some use cases where such constraints don't exist at all.
If you still allow transactions that span multiple statements, you would still potentially have dirty reads.  

Imagine that I have a simple banking application where session 1 is trying to transfer $100 from account A to account B.  Session 1 starts a transaction and subtracts $100 from A.  Now session 2 runs a report that tries to make sure that money hasn't gone missing (which is somewhat useful if you are running a bank).  If session 2 is allowed to read the updated balance from A and the un-updated balance from B because session 1 is in the middle of a transaction, it has done a dirty read.  The fact that session 1 is going to eventually commit the change does not change the fact that session 2 was able to get an inconsistent view of data.

Of course, a database that disallowed rollbacks but allowed transactions that spanned multiple statements would be rather problematic.  If I subtract $100 from A and then try to add $100 to B but I encounter an error trying to update B (perhaps I discover that there is a hold on B or that B has been closed), I'm in a pretty unfortunate position.  Assuming I don't want $100 to disappear into thin air (which will make A rather unhappy), my application has to catch the exception and manually implement a rollback by putting the $100 back.  In real applications where transactions involve changes to a bunch of different tables, some of which are done by triggers that the application may not be aware of, that is a non-trivial challenge.