mORMot Open Source

bernd.maierhofer

Member

Registered: 2015-03-03

Posts: 3

Some basic questions

Hi + tx for reading. i would be glad, if someone can answer my questions or will lead me to the according docs.

- How is concurrency handled?
- I have seen a method for propgating changes to the model automatically to the underlying database. E.g. A new Version of my app modifies the DB accoirdingly. But what if the old version runs too afterwards? Are the changes undone?
- I am coming from Client Server programming and would appreciate a sample where data is fetched from a database table, displayed, modified and written back.

Thank you very much!

Bernd

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,673

Website

Re: Some basic questions

1. Concurrency.
What do you mean?
At HTTP level, concurrency is handled via a IOCP server and a thread pool.
At ORM level, there are several options - see http://synopse.info/files/html/Synopse% … ml#TITL_25
At SOA level, see http://synopse.info/files/html/Synopse% … ml#TITL_72
At Client level, there is a LOCK option to lock a record. But it is not a very good idea on production, so you would rather use a dedicated SOA service, and/or a TSQLRestBatch with dual-phase commit.

2. The only model change handled is adding a field, which will generate a ALTER TABLE ADD COLUMN statement.
There is no "undo" feature. But I guess that if an old version runs afterwards, the new column won't harm. But your business logic may be broken - not due to the ORM.

3. Do you mean with client UI, and a TDataSet?
There is no single sample of it yet... since there are several ways of doing it.
See sample "28 - Simple RESTful ORM Server" and "17 - TClientDataset use".
You may take a look at "SQLite3\Samples\ThirdPartyDemos\Migajek\synopse-sqlite-demo".

bernd.maierhofer

Member

Registered: 2015-03-03

Posts: 3

Re: Some basic questions

Concurrency:
User A retrieves Record A, the same does user B. User A changes the data, as well as user B. Both want to commit. Who wins?
BTW: Is a deadlock possible?

Tx Bernd

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,673

Website

Re: Some basic questions

Last write wins, as with a regular db with two transactions.

No race condition possible, since there is no blocking lock.

mathias_burbach

Member

Registered: 2020-07-11

Posts: 1

Re: Some basic questions

Dear Administrator,

a pessimistic lock as suggested by Bernd is one option. I can understand that you do not want to implement that feature for a stateless server.

But what about optimistic locking? I am studying mORMot to decide if my next project will be done with mORMot instead of DataSnap and TClientDataSets. So far I have had a version number on each record that was incremented by the application server. The primary key value and the version number of the record was good enough to identify if the record changed since the client-side fetched the record. Obviously the server had to increment the version number and that change on the record was transported back into the client without a single line of code. Just by including the poPropogateChanges into the TDataSetProvider.Options any server-side change was transported back into the client.

I thought that TModTime would be something similar as I looked at the mORMot documentation. But in the sample project 03 NamedPipe the value is assigned on the client-side. Even if there is a chance to get this done on the server-side I would still need other properties to be updated on the server-side before they are saved in the database and that change would have to go back into the client-side without too much effort. What is the best way to achieve that with mORMot?

A sample on how TMS Aurelius handles such situations can be found here.

Salut,
  Mathias

Last edited by mathias_burbach (2020-07-17 04:42:15)

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,673

Website

Re: Some basic questions

Locking on client side, even "optimistic", is a no-option for any scaling service.

DataSnap and TDataSet are clearly completely diverse beasts than mORMot SOA + ORM features.
mORMot services are not data-centric, as any modern REST MicroService would.
Defining clean service endpoints with dedicated DTOs is mandatory for any serious work.

If you want clients synchronization in mORMot, we have an unique ORM feature, which is master/slave replication. It could be done either on demand, on in real time, using a WebSockets link.
Check https://synopse.info/files/html/Synopse … l#TITL_147
As a fallback, for most simple scenarios, the cache implemented in mORMot allow also very simple polling from the client side: checking for a modification of a given record is executed in a few microseconds (not milliseconds) on the server side.

For implementing any service on the server side, I would forget about TDataSet, and use our ORM, or our native SynDB classes. It is much faster than a TDataSet e.g. when retrieving a single row of data = a single object.