Due to the HTTP thread pool, TransactionBeginRetry and Commit/Rollback will probably not be run in the same thread, so in the same connection.
For SQlite3, it is not an issue.
But for OleDB/MSSQL, it is a problem.

Temporary solution is to run the transaction on the server side.

This proposal is to introduce a dedicated thread, at least for the write process.

In the current implementation, ORM writes are protected by a critical section..
We may improve it to (optionally) regroup all this write process within a dedicated background thread. It won't be much slower, but safer to work with, and it will fix the transaction issue (and also use less resources)..
ORM reads could still be executed within the thread pool, for better speed, or optionally use the same background thread.

ab added on 2014-03-15 20:53:23 UTC:
If you have an external database engine which expect transactions to take place in the same thread, you can now ensure that TSQLRestServer force execution of this method when accessed from RESTful clients in the same thread, by writing e.g.

 aMyServer.AcquireExecutionMode[execORMWrite] := amBackgroundThread;

This should fix the issue.

For performance, the best is to maintain all your transactions on the server side, e.g. by writing all the complex DB process in an interface-based service. For interface-based services, you can force the execution of the same instance or the same session to take place in the same thread, by setting:

aServiceFactoryServer.SetOptions('',[optExecInPerInterfaceThread, optFreeInPerInterfaceThread]);