Server side transactions

[lvca]

Right now ArcadeDB HTTP/JSON protocol is totally stateless. This allows to use the transactions only with SQL scripts, but it's not the most user-friendly API to use.

I think the easiest thing to do is to bind a client session to a server-side session. On the server side, we could create a session id as a UUID and send it to the client at authentication as a token. If the client passes this token in the HTTP request header, then the server looks for the session id. In this way, we could save a transaction object and expose the begin + commit commands in the remote database API.

[tetious]

What about some kind of hybrid, where it is stateless unless you need it to be stateful? Would it be too weird/complicated to start a session when you begin the transaction and end it when you commit/rollback? Are other cases where state would add value, too?

Keeping statefulness "opt-in" seems to fit well with the flexibility of the rest of the API and might be ideal.

What would happen to transactions that leak due to never getting committed/rolled back? Would the transaction/session thing have a timeout where it automatically rolls back?

[lvca]

I think it's a great idea. The session is started upon the new begin HTTP command. it will return a transactionId as a UUID. After that, we have to define a default timeout in the global configuration (so the user can easily configure it). I'm renaming this issue fro Server side sessions to "Server side transactions", because it will cover only transactions.

[lvca]

Created issue #139. Everything is implemented. Waiting for the PR to check for any regressions.

[lvca]

Merged, welcome to the server-side transactions. Thanks @tetious for your inputs.

[tetious]

Oh awesome! I’ll add support for this to my .net library tonight, hopefully.