You are not logged in.
Hi Everyone,
I am new to mORMot framework and I have a question about it.
Does mORMot have any feature like Reconcile Error Event (Delphi 's DataSnap)?
Ex.
1) User A and User B retrieve the same record
2) User A edits and saves the record
3) User B edits and saves the record after User A commits transaction
4) User B gets an error message 'Record changed by another user' and Rollback Transaction.
I found mORMot framework is so amazing and I really want to move from DataSnap to mORMot but my boss still loves DataSnap cause it only has Reconcile Error feature!)
Thank you very much,
Chowong
Offline
There is no direct equivalency of this "reconciliation" feature, because it is very specific to the database backend used.
It expects a single database engine, with proper transaction support.
And a rollback is IMHO not the best way to solve the concurrent access problem.
In fact, such process expect a centralized transaction process, which may be very complex when you have several databases at once, as mORMot features: you may have the ORM store some collections in memory, others in SQlite3, others in a remote Oracle server, others in MSSQL, others in NoSQL at the same time. Maintaining a global transaction state is very hard, and you need "gaz factory" centralized systems. And some databases do not even support ACID transactions - see http://blog.synopse.info/post/2014/02/2 … bases-ACID
So there are several "mORMot" ways of doing "reconciliation":
1. Simply use the LOCK feature of the REST interface, i.e. using TSQLRest.Retrieve() with "forUpdate=true" parameter, followed by a TSQLRest.UnLock() call.
2. Or use the aggregate concept http://synopse.info/files/html/Synopse% … l#TITL_124 so that such conflicts won't occur.
3. Use a BATCH following the "Unit of work" pattern http://synopse.info/files/html/Synopse% … l#TITL_100
4. Have your own local read/write database on client side, replicated as read-only on the main server via http://synopse.info/files/html/Synopse% … ATION4_EMF - it has the ability to work OFFLINE, which may be a very good point.
5. Use an "optimistic" approach, so that the last commit would overwrite the previous modification, but use automatic change tracking of the record to provide an history of all changes, so conflicts are easier to resolve - see http://synopse.info/files/html/Synopse% … #TITLE_107 - this may be seen as a "Reconcile on steroid" feature, since it is much more powerful than a simple rollback.
There are several ways of resolving the concurrent edition issue of a record in mORMot, and IMHO they are worth investigating.
Simply rollbacking the transaction is IMHO very frustrating for the user. He/she just lost all his/her edition work...
Offline
Thank you so much ab. I will try each way above.
Offline