Search This Blog

Thursday, October 22, 2015

Avoiding the GetObjectsNonReenterant error for security permissions with complex criteria


During further testing we found that the new solution is not appropriate for certain scenarios (e.g., when new objects are created and saved under certain scenarios) and eventually decided not to make this new mode as default in v15.2. We will also mark the CanCheckModifiedObject option as obsolete for now. We will try to approach this problem from another angle at a lower XPO level. As always, we will keep you posted of our results once have anything to share. We apologize for all the inconvenience here.

Let me quote myself from the Security - Avoid the GetObjectsNonReenterant error while evaluating security permission criteria involving collections during the object saving procedure thread in our Support Center:

We have provided the new CanCheckModifiedObject property in the DevExpress.ExpressApp.Security.SecurityRule class, which can be used to avoid loading additional collections and thus throwing the "GetObjectsNonReenterant" error from XPO internals while evaluating security permission criteria during the object saving procedure.

If CanCheckModifiedObject = True, both currently modified and existing database records are validated by security rules (the current behavior leading to the error).

Otherwise, if CanCheckModifiedObject = False, only the existing database records are validated by security rules. The latter configuration should be suitable in most business scenarios we are aware of and this will be the default configuration in v15.2.

Thus, to avoid the "Entering state 'GetObjectsNonReenterant' from state 'CommitTransactionNonReenterant, CommitChangesToDataLayer' is prohibited due to state 'CommitChangesToDataLayer' for 'DevExpress.Xpo.UnitOfWork(35)'" error in v15.1.8+
set the static DevExpress.ExpressApp.Security.SecurityRule.CanCheckModifiedObject property to False in the entry point of your application; e.g., within the constructor of your platform-agnostic module (YourSolutionName.Module/Module.xx) OR within the Main method of the WinForms app (YourSolutionName.Win/Program.xx) OR within the Application_Start method of the ASP.NET app (YourSolutionName.Web/Global.xx).

For instance, below is the code I added in the MainDemo.Module/Module.cs file of the project from the E4045: 
How to separate data between employees and managers of different departments using security permissions example while testing this improvement locally:

using DevExpress.ExpressApp;

namespace MainDemo.Module {
  public sealed partial class MainDemoModule : ModuleBase {
    public MainDemoModule() {
      DevExpress.ExpressApp.Security.SecurityRule.CanCheckModifiedObject = false;

We would greatly appreciate you downloading this hot-fix build or waiting for the official v15.1.8 maintenance update and testing this behavior in action with your project to see if it meets your needs.
If this does not fully suit you, please submit separate tickets via the Support Center and describe the most important use-case scenarios and expected results that you wish to achieve with our security module. Thanks in advance!


  1. Hi Dennis,

    I'm really sorry to hear that this change wont make it for 15.2. I was really looking forward to it as dealing with 'GetObjectsNonReenterant' error can sometimes be a real pain. Hope that you guys will introduce the new behavior as soon as possible.

    Keep up the good work,


    1. Thanks for your feedback, Aleksandar. We'll try to solve this in a different way

    2. @Aleksandar: Please try our new solution from
      Thanks for your time in advance!