This question is locked. New answers and comments are not allowed.
How do I implement a winforms application that provides a solution for the multi-user use case of a team of users sharing the same database?
I see various references to L2 Cache and INotifyPropertyChanged event; but they are not explicitly attached in the documentation to the multi user case that all scalable databased applications must deliver.
Specifically, if user A changes a record and commits it to database while user B is making changes, then user B should receive notification that the record has been changed during his/her edits. How can I implement this using Telerik's ORM? (In other systems, this used to be implemented as a reread and compare before commit mechanism in a transaction.)
A second case is if the list of records in the BindingSource(s) used in the application has changed on the database, how does the application know to refresh or simply update the BindingSource(s)?
I read the L2 Cache information in light of this use case and I am not convinced that I'm reading anything relevant. As far as I understand it the L2 Cache seems to be on each client workstation independently.
Is there a jargon-free description of how to solve these two use cases using Telerik's ORM?
1. Two users simultaneously editing the same record.
2. Application BindingSource lists dynamically responding to CRUD activity on the database.
Regards,
Guy
I see various references to L2 Cache and INotifyPropertyChanged event; but they are not explicitly attached in the documentation to the multi user case that all scalable databased applications must deliver.
Specifically, if user A changes a record and commits it to database while user B is making changes, then user B should receive notification that the record has been changed during his/her edits. How can I implement this using Telerik's ORM? (In other systems, this used to be implemented as a reread and compare before commit mechanism in a transaction.)
A second case is if the list of records in the BindingSource(s) used in the application has changed on the database, how does the application know to refresh or simply update the BindingSource(s)?
I read the L2 Cache information in light of this use case and I am not convinced that I'm reading anything relevant. As far as I understand it the L2 Cache seems to be on each client workstation independently.
Is there a jargon-free description of how to solve these two use cases using Telerik's ORM?
1. Two users simultaneously editing the same record.
2. Application BindingSource lists dynamically responding to CRUD activity on the database.
Regards,
Guy
6 Answers, 1 is accepted
0
Hello Guy,
Zoran
the Telerik team
For the first question, OpenAccess has built-in concurrency control functionality, and takes care for you in the case where two users are updating the same record simultaneously. If you get into such scenario, an OptimisticVerificationException will be thrown and that way you will be alerted for this situation.
OpenAccess does not monitor the database continuously so that it can react when a record has been added there by another process. This is logic that your application should contain in order for you to always have the grid refreshed whenever an object has been added.
Zoran
the Telerik team
0
Guy
Top achievements
Rank 1
Rank 1
answered on 20 May 2011, 01:38 AM
Zoran,
Thank you for your response. Is there an example of OptimisticVerificationException in your source examples? I have to assume it is thrown during SaveChanges.
There is no support for the BindingSource becoming obsolete? In other words, every time a user moves between records the safest thing to do is refresh the BindingSource? Where does this L2 Cache come into play?
Regards,
Guy
Thank you for your response. Is there an example of OptimisticVerificationException in your source examples? I have to assume it is thrown during SaveChanges.
There is no support for the BindingSource becoming obsolete? In other words, every time a user moves between records the safest thing to do is refresh the BindingSource? Where does this L2 Cache come into play?
Regards,
Guy
0
Hello Guy,
Zoran
the Telerik team
Unfortunately there is no example for throwing an OptimisticVerificationException as it would be complex for the users to achieve that(the example should be run by two users simultaneously). However we do consider making a video for showing this support to the customers. And yes, you are correct, the exception is thrown during SaveChanges().
Regarding the BindingSource, you are assuming correctly, the user should manually refresh the BindingSource. The L2 cache is however refreshed automatically when a user performs an action that modifies a record in the database. E.g. if an object is cached and a user edits it, the object will be evicted from the cache. When a second user asks for the same object, the object will not be returned from the cache, but from the database instead so that the latest version from the object is obtained.
Zoran
the Telerik team
0
Guy
Top achievements
Rank 1
Rank 1
answered on 20 May 2011, 02:07 PM
Understand that I have to know exactly how your technology works to provide precise solutions to the concurrent use cases.
With OptimisticVerificationException, the user session which saved first will not receive the exception but the second session will. Correct me if I'm wrong. On the second session, after said exception, the application should notify the user that another user saved changes while current session edits were made. At that point, does the exception provide any further information? I would like to somehow allow the user to decide whether to overwrite, merge or accept the recent changes.
L2 cache is only available if I have enabled it using MSMQ for each workstation. Correct? I understand it is not the default configuration. If I do use the L2 cache then rereading the BindingSource for each record move should be swift. Correct? As a design consideration, if the user is on record N and clicks to move to record N+1, then should I try to limit the refreshing to those records until the next is retrieved? (N+1 in this user's BindingSource may now be deleted on the database or may be N+2 or higher after other insertions.) It seems crazy to refresh the whole BindingSource for each move. But perhaps that is why you have the L2 cache... to prevent the database server from being inundated with requests as the user team moves around records.
Finally, if I may ask about your documentation on how to modify your templates to provide INotifyPropertyChanged, what purpose does this serve. Is this INotifyPropertyChanged another way to manage concurrency?
Regards,
Guy
With OptimisticVerificationException, the user session which saved first will not receive the exception but the second session will. Correct me if I'm wrong. On the second session, after said exception, the application should notify the user that another user saved changes while current session edits were made. At that point, does the exception provide any further information? I would like to somehow allow the user to decide whether to overwrite, merge or accept the recent changes.
L2 cache is only available if I have enabled it using MSMQ for each workstation. Correct? I understand it is not the default configuration. If I do use the L2 cache then rereading the BindingSource for each record move should be swift. Correct? As a design consideration, if the user is on record N and clicks to move to record N+1, then should I try to limit the refreshing to those records until the next is retrieved? (N+1 in this user's BindingSource may now be deleted on the database or may be N+2 or higher after other insertions.) It seems crazy to refresh the whole BindingSource for each move. But perhaps that is why you have the L2 cache... to prevent the database server from being inundated with requests as the user team moves around records.
Finally, if I may ask about your documentation on how to modify your templates to provide INotifyPropertyChanged, what purpose does this serve. Is this INotifyPropertyChanged another way to manage concurrency?
Regards,
Guy
0
Guy
Top achievements
Rank 1
Rank 1
answered on 23 May 2011, 04:34 PM
From my most recent post:
"Finally, if I may ask about your documentation on how to modify your templates to provide INotifyPropertyChanged, what purpose does this serve. Is this INotifyPropertyChanged another way to manage concurrency?"
I would like to know on a Form whether anything has been changed. Then a revert button can become enabled to allow the user to revert the changes (I would prefer an undo sequence). Is this what INotifyPropertyChanged indicates? I can reread the persistant object when Revert is clicked and L2 will work behind the scenes.
"Finally, if I may ask about your documentation on how to modify your templates to provide INotifyPropertyChanged, what purpose does this serve. Is this INotifyPropertyChanged another way to manage concurrency?"
I would like to know on a Form whether anything has been changed. Then a revert button can become enabled to allow the user to revert the changes (I would prefer an undo sequence). Is this what INotifyPropertyChanged indicates? I can reread the persistant object when Revert is clicked and L2 will work behind the scenes.
0
Hi Guy,
Please ignore the L2 cache for the moment, the OpenAccess behavior from the UI perspective is the same. Think about it as optimization, not as feature that changes your application's behavior.
The INotifyPropertyChanged interface reports to all bound UI element if that object has been changed. This means if you do a refresh on the object to get the latest content from the db, the UI elements are notified and can display the new state.
The OptimisticVerificationException has a Conflict method where you can find the exact cause of the exception. My feeling is, that you expect a complete notification chain from one client via the db to all other clients. This is a very complicated, slow and error pron setup and we do not support it.
Let's talk about the lifecycle of the data in memory. As long as the transaction is running, which is always the case with the context, the data that is loaded once is not refreshed except you do it explicitly. After the SaveChanges or ClearChanges all objects are set to invalid and if you touch them they are automatically refreshed from the db. What you can do now is to call SaveChanges immediately before the user starts changing something. That reduces the time frame for a concurrency control failure.
If you have your application running and you do only changes via OpenAccess to the database, you can think about enabling the L2 cache. You application should now behave faster.
Regards,
Jan Blessenohl
the Telerik team
Please ignore the L2 cache for the moment, the OpenAccess behavior from the UI perspective is the same. Think about it as optimization, not as feature that changes your application's behavior.
The INotifyPropertyChanged interface reports to all bound UI element if that object has been changed. This means if you do a refresh on the object to get the latest content from the db, the UI elements are notified and can display the new state.
The OptimisticVerificationException has a Conflict method where you can find the exact cause of the exception. My feeling is, that you expect a complete notification chain from one client via the db to all other clients. This is a very complicated, slow and error pron setup and we do not support it.
Let's talk about the lifecycle of the data in memory. As long as the transaction is running, which is always the case with the context, the data that is loaded once is not refreshed except you do it explicitly. After the SaveChanges or ClearChanges all objects are set to invalid and if you touch them they are automatically refreshed from the db. What you can do now is to call SaveChanges immediately before the user starts changing something. That reduces the time frame for a concurrency control failure.
If you have your application running and you do only changes via OpenAccess to the database, you can think about enabling the L2 cache. You application should now behave faster.
Regards,
Jan Blessenohl
the Telerik team