Transactions in NoSQL?

Generally speaking, NoSQL solutions have lighter weight transactional semantics than relational databases, but still have facilities for atomic operations at some level.

Generally, the ones which do master-master replication provide less in the way of consistency, and more availability. So one should choose the right tool for the right problem.

Many offer transactions at the single document (or row etc.) level. For example with MongoDB there is atomicity at the single document - but documents can be fairly rich so this usually works pretty well -- more info here.

Depends on your DB, but ... I would say in general, you can use 'Optimistic transactions' to achieve this but I imagine one should make sure to understand the database implementation's atomicity guarantees (e.g. what kind of write and read operations are atomic).

There seems to be some discussions on the net about HBase transactions, if thats any help.

You can always use a NoSQL approach in a SQL DB. NoSQL seems to generally use "key/value data stores": you can always implement this in your preferred RDBMS and hence keep the good stuff like transactions, ACID properties, support from your friendly DBA, etc, while realising the NoSQL performance and flexibility benefits, e.g. via a table such as

CREATE TABLE MY_KEY_VALUE_DATA
(
    id_content INTEGER PRIMARY KEY,
    b_content  BLOB
);

Bonus is you can add extra fields here to link your content into other, properly relational tables, while still keeping your bulky content in the main BLOB (or TEXT if apt) field.

Personally I favour a TEXT representation so you're not tied into a language for working with the data, e.g. using serialized Java means you can access the content from Perl for reporting, say. TEXT is also easier to debug and generally work with as a developer.