ROLLBACK after COMMIT
Generally, a transaction is exactly one of


committed
rolled back


Committed transactions are never rolled back. 
It's how all RDBMS operate, on ACID principles

Now, there are some different cases where it may look like this rule has been broken. But it hasn't.

Before we look at these cases though, different user sessions do not share a connection. Each user/client has one connection to the SQL and all are isolated from each other. Connection pooling does not affect this.

Savepoints

You can SAVE a transaction and rollback to this savepoin,

That is, you can partially commit/rollback if you use savepoints but I've never seen anyone do this in real life code. I won't expand more.

Nested transactions

You can nest transactions but they don't really mean anything
Simply put, SQL Server does not really have nested transations even if @@TRANCOUNT can be higher than one.


A begin increments @@TRANCOUNT by one
A rollback will set @@TRANCOUNT to zero
A commit decrements @@TRANCOUNT by one


A longer explanation is in this SO answer