SessionID in TSQLRest.TransactionBegin()

Junior/RO · 2013-01-25 15:43:39

AB,

When using TSQLRestClientDB.TransactionBegin(), the SessionID parameter is optional. When using ancestor TSQLRest.TransactionBegin(), then SessionID is not optional.

I was trying to figure why exist this different implementation. Can you tell us about this SessionID parameter?

Also, Commit() and Rollback() have this differences.

Last edited by Junior/RO (2013-01-25 15:44:36)

ab · 2013-01-25 18:50:23

This is the SessionID.... from the session of the authentication.
It is the only way we found out to ensure that the very same client is trying to initiate and commit/rollback a transaction.
If you are not authenticated (e.g. with a local direct access), such a checking may be superfluous, so was made optional.

I'm not very proud of the transaction process with mORMot.
In fact, in a multi-threaded environment, transactions may be confused, depending on the db engine used (with SQlite3 it should be OK, but with external DBs, the current implementation is not fully tested/proven).

I'm thinking about:
- Getting rid of the transaction RESTful process from the client side;
- Allowing transactions on the server side only (which can be protected with a critical section);
- Letting client side process have a transaction, but integrated in BATCH mode - up to now, BATCH mode does not create a transaction, but I guess it should be the best way of making transactions as small as possible.

But I suspect BATCH mode should be enhanced to allow direct replacement of created IDs during the batch process: e.g. create both master and detail rows, returning a negative ID to mark that it is not a true ID, then recognize it during the BATCH process itself on server side, then replace the negative ID by the truly ID, as just created and received from the DB.

This will implement the so-called Unit Of Work pattern.

MSDN article wrote:

In a way, you can think of the Unit of Work as a place to dump all transaction-handling code.
The responsibilities of the Unit of Work are to:
- Manage transactions.
- Order the database inserts, deletes, and updates.
- Prevent duplicate updates. Inside a single usage of a Unit of Work object, different parts of the code may mark the same Invoice object as changed, but the Unit of Work class will only issue a single UPDATE command to the database.
The value of using a Unit of Work pattern is to free the rest of your code from these concerns so that you can otherwise concentrate on business logic.

So my advice is, with the current state of mORMot:
- Use transactions on Server side only (e.g. within a service);
- Use a BATCH to maintain the transaction as short as possible.

Junior/RO · 2013-01-25 20:29:00

In this case, this is a stand-alone application.

And I don't know if, inside a transaction, when calling Client.Add() I should to use the SendData parameter as True or False.

ab · 2013-02-11 07:00:43

Is the documentation not clear enouch?

TSQLRest.Add documentation wrote:

// - if SendData is true, client sends the current content of Value with the
// request, otherwize record is created with default values

If SendData=false, the published properties values are not written: only a new void row is inserted, and the method returns the created ID.
If SendData=true, the published properties values are written to the new database row - this is the expected behavior most of the time, I suspect.

edwinsn · 2017-01-06 16:47:46

@ab,

Sorry for posting to this old thread - so with the latest version of mORMot, does the SessionID parameter still make sense for the client-side transactions? Thanks.

ab · 2017-01-06 16:53:07

Yes I think so.

But client side transactions are not a good way of doing transactions with mORMot.

edwinsn · 2017-01-06 17:26:01

Yes, I know batch-mode is the way to go, but there are some legacy code I cannot convert to batch mode yet.

So back to the SessionID question - when there are multi-clients and all of the clients are using the same default value (which is 1, according to the method definition), will there be conflicts? Thanks.

ab · 2017-01-06 21:47:40

Each client should have a true authenticated session, so that each client will have its own session ID.

edwinsn · 2017-01-07 05:51:07

ab, the program is being used in a local secure network, so I did not implement the authentication, so in this case, should I still provide a unique "SessionId" for each client? Thanks.

ab · 2017-01-07 10:22:59

Yes, as I wrote, you should have a unique SessionID.
So in such case, you could use a weak authentication, with a shared user, even the default "User"/"synopse" from each client.

Note that from the security point of view, there is no such thing as a "secure local network"... If your server is bound to something else than localhost, you may have for sure potential weaknesses, the biggest being between the chair and the keyboard of the end-user.

edwinsn · 2017-01-08 03:44:04

@Ab,

Thank you very much for the info! So I've applied the default http authentication using one of the 3 default users defined by the mORMot framework itself.

Have a nice weekend!

mORMot Open Source

#1 2013-01-25 15:43:39

SessionID in TSQLRest.TransactionBegin()

#2 2013-01-25 18:50:23

Re: SessionID in TSQLRest.TransactionBegin()

#3 2013-01-25 20:29:00

Re: SessionID in TSQLRest.TransactionBegin()

#4 2013-02-11 07:00:43

Re: SessionID in TSQLRest.TransactionBegin()

#5 2017-01-06 16:47:46

Re: SessionID in TSQLRest.TransactionBegin()

#6 2017-01-06 16:53:07

Re: SessionID in TSQLRest.TransactionBegin()

#7 2017-01-06 17:26:01

Re: SessionID in TSQLRest.TransactionBegin()

#8 2017-01-06 21:47:40

Re: SessionID in TSQLRest.TransactionBegin()

#9 2017-01-07 05:51:07

Re: SessionID in TSQLRest.TransactionBegin()

#10 2017-01-07 10:22:59

Re: SessionID in TSQLRest.TransactionBegin()

#11 2017-01-08 03:44:04

Re: SessionID in TSQLRest.TransactionBegin()

Board footer