Oh, dbafreak, I now understood your point. We didn't understood at the begening because NOT any single RDBMS server would react like you'd like . An unfinished transaction is NEVER commited by the server itself, by its willing. It is a deontological problem, a principle problem, here. The server commit only the explicitly commited transaction, or the transaction that the technology EXPLICITLY explined to you they will do an implicitly commit (like DDL, for instance).
The database server could NOT know how long should your transaction be. If it would commit an unfinished transaction, it by itself would be putting the data it is keeping as a main task into an UNCONSISTENT state. Maybe the rows you just changed have some business rules associated, as they modification implies willy-nilly some other modifications that didn't occur because of that power failure, and from the business rules point of view, the data are inconsistent. And keeping data is what a database do. It is unacceptable for a server to commit itself some changes. WE don't want it to do so. This is why the transactions were invented!
And for this purpose, the ONLY solution, accepted by ANY RDBMS system, is to rollback all the uncommited transactions in course at the failure moment.

From my knowledge, there isn't any RDBMS system so smart that is capable to RESUME on another further connection an unfinished transaction.

It could be possible to be some High-Availability cluster systems that could take the load if one server fails, but I don't know if this kind of systems resume by itself a transaction, or the application itself is written in a way that let the system to rollback and THEN re-initialise the transaction on the other server. I don't know.

I hope I was clear now. If not, ask again.
Bye,
ovidius