locked
How can I control 'Concurrency Conflict Detection' in LightSwitch Html Client? RRS feed

  • Question

  • How can I control 'Concurrency Conflict Detection' in LightSwitch Html Client?  Code???

    DataArtist

    Tuesday, November 18, 2014 7:22 PM

Answers

  • Hi,

    LightSwitch automatically detects concurrency conflicts, but you can improve the performance of an application in some cases by understanding how LightSwitch handles that process .

    LightSwitch handles conflicts slightly differently depending on what data source is being used.

    For more information,please check:

    http://msdn.microsoft.com/en-us/library/jj635147.aspx

    Besides, link below could give you some help:

    http://blogs.msdn.com/b/lightswitch_rocks1/archive/2011/08/19/how-to-handle-database-concurrency-issues.aspx

    Best Regards,


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.




    Wednesday, November 19, 2014 5:49 AM
  • Hi Todd,

    TL;DR : not possible unless you construct your own Http Post request and analyse the server response for getting the concurrency error.

    While in the silverlight client the support or this type of behavioral augmentation is outstanding, in the html client you are unfortunately more on your own.

    Inside the msls-2.x file you'll find a function TryGetServerErrors which is called after a Post (the save operation). That function is quite involved but the code we are interested here is:

    else {
                        if (jMessageXML.find("EntityConflicts").length > 0) {
                            nonValidationErrorMessage = msls_getResourceString("conflict_dialog_message");
                        } else {
                            nonValidationErrorMessage = jMessageXML.find("Message").text() || messageValue;
                        }

    Now, my intuition was that in case you would do the save operation yourself, by putting a custom save button on your screen and calling following code you could intercept that error popup:

    screen.details.dataWorkspace.ApplicationData.saveChanges().then(oncomplete, onerror);
        function oncomplete(d) {
            // do something
        };
    
        function onerror(err) {
            // do something
        };

    Unfortunately, the saveChanges callback is triggered after TryGetServerErrors.

    So, you need to go one level deeper and construct the Post request yourself by hand and mimic the logic in the response handling similar to what you find in TryGetServerErrors.

    I'm not sure this is something you *want* to do.

    I'm quite confident that the product team will improve this kind of stuff in later releases of LightSwitch and bring things up to the same level as the silverlight client.




    paul van bladel ==independent enterprise application architect== http://blog.pragmaswitch.com


    Tuesday, November 25, 2014 3:59 PM

All replies

  • Hi,

    LightSwitch automatically detects concurrency conflicts, but you can improve the performance of an application in some cases by understanding how LightSwitch handles that process .

    LightSwitch handles conflicts slightly differently depending on what data source is being used.

    For more information,please check:

    http://msdn.microsoft.com/en-us/library/jj635147.aspx

    Besides, link below could give you some help:

    http://blogs.msdn.com/b/lightswitch_rocks1/archive/2011/08/19/how-to-handle-database-concurrency-issues.aspx

    Best Regards,


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.




    Wednesday, November 19, 2014 5:49 AM
  • Thanks for the input.  I understand that LightSwitch automatically detects concurrency conflicts, but wanted to augment its behavior in the Html Client.   One of the links you provided addresses doing this in the Silverlight client but I'm interested in the Html Client.  I believe that there are different approaches to augmenting concurrency in each of these clients.  For my application I'd love to override concurrency in the Html Client to force a 'last write wins' approach without a prompt.  Is this possible?

    Thanks,

    Todd

      

    DataArtist

    Monday, November 24, 2014 6:03 PM
  • Hi Todd,

    TL;DR : not possible unless you construct your own Http Post request and analyse the server response for getting the concurrency error.

    While in the silverlight client the support or this type of behavioral augmentation is outstanding, in the html client you are unfortunately more on your own.

    Inside the msls-2.x file you'll find a function TryGetServerErrors which is called after a Post (the save operation). That function is quite involved but the code we are interested here is:

    else {
                        if (jMessageXML.find("EntityConflicts").length > 0) {
                            nonValidationErrorMessage = msls_getResourceString("conflict_dialog_message");
                        } else {
                            nonValidationErrorMessage = jMessageXML.find("Message").text() || messageValue;
                        }

    Now, my intuition was that in case you would do the save operation yourself, by putting a custom save button on your screen and calling following code you could intercept that error popup:

    screen.details.dataWorkspace.ApplicationData.saveChanges().then(oncomplete, onerror);
        function oncomplete(d) {
            // do something
        };
    
        function onerror(err) {
            // do something
        };

    Unfortunately, the saveChanges callback is triggered after TryGetServerErrors.

    So, you need to go one level deeper and construct the Post request yourself by hand and mimic the logic in the response handling similar to what you find in TryGetServerErrors.

    I'm not sure this is something you *want* to do.

    I'm quite confident that the product team will improve this kind of stuff in later releases of LightSwitch and bring things up to the same level as the silverlight client.




    paul van bladel ==independent enterprise application architect== http://blog.pragmaswitch.com


    Tuesday, November 25, 2014 3:59 PM
  • Thank you Paul for your detailed response.  I really appreciate the time you took to explain where the LightSwitch Html Client is at this point in regards to concurrency.

    Todd


    DataArtist

    Tuesday, November 25, 2014 4:16 PM
  • My pleasure Todd.

    paul van bladel ==independent enterprise application architect== http://blog.pragmaswitch.com

    Tuesday, November 25, 2014 4:48 PM
  • I know this post is a little bit outdated, but I managed to overcome such issue by discarding changes if conflict occurs.

        $.each(screen.TransactionHeaders.data, function (key, entity) {
            entity.details.discardChanges();
        });
        screen.TransactionHeaders.refresh();

    Friday, May 8, 2015 12:45 PM
  • Hi vsamsinovs, I'm interested in your solution.  Could you explain more about where you are calling this code?  is it contained in some larger block that detects the concurrency issue?  Thanks.
    Friday, May 8, 2015 2:24 PM
  • Hi Hessc,

    I don't know how to detect this issue prior to saving, so here is my code:

     myapp.applyChanges().then(function () {
            toastr.success("Entity Saved");
        }, function fail(e) {
            if (e.message ==

    "The data you are editing has been updated by another transaction. Please refresh the page and try again.") {
                conflictFix(screen);
            }
            if(e.noErrorDialog != true)
                toastr.error(e.message||e);
        });

    function conflictFix(screen) {
        $.each(screen.TransactionHeaders.data, function (key, entity) {
            entity.details.discardChanges();
        });
        screen.TransactionHeaders.refresh();
    }

    Now, all I'm doing is discarding changes and refreshing data which fixes the conflict. What you can do, is prior to discarding changes save them in array and populate again after refresh. 

    I very rarely see this error in my application, so it works for me. However, it can be improved very easily :)
    • Edited by vsamsinovs Saturday, May 9, 2015 9:49 AM
    Saturday, May 9, 2015 9:46 AM