That would require to save state on the server what I tried to get rid of actually. Since we don't have a way to keep connections open, I'm not even sure if we could do this as we have no way of keeping the same connection over multiple messages.

You would need to pool connections (like a JDBC connection pool does).

You would not need to maintain the entire state of the transaction on the server, but what you're doing now is forcing the client to maintain that state, which could lead to OOM.

So... in more detail... if a user starts a transaction you need to get a connection from the pool and put it in transaction mode, then as more commands arrive for that connection you apply them against that same connection (and nothing else can use that connection).

Okay, I guess this is something we should be able to do as soon as we have a ConnectionPool. We still don't have this as we need a true async pooling solution. Mauricio and me don't know how to do that. You told me, that you have done something like that in HttpClient but I have to admit that I didn't really understood how that worked and how it was really asynchronous due to the synchronized keywords. Maybe I can have a look at it during the holidays, but I can't promise anything right now :(

There's nothing particularly complex about an asynchronous pool, here's an example: https://github.com/eclipse/vert.x/blob/master/vertx-core/src/main/java/org/vertx/java/core/http/impl/PriorityHttpConnectionPool.java

Finally, the new way to handle transactions made it into 0.3.0 release. Thanks!