DevExpress XAF is a framework for .NET and Visual Studio developers who wants to create Office-like LOB apps for desktop, web and mobile faster and without hiring a large team.
Thursday, October 22, 2015
Avoiding the GetObjectsNonReenterant error for security permissions with complex criteria
UPDATE2
UPDATE1
OUTDATED
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:
Please see my latest "The GetObjectsNonReenterant error for security permissions with complex criteria - Fixed in v15.2.5" blog post.
UPDATE1
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.
OUTDATED
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() {
InitializeComponent();
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!
Subscribe to:
Post Comments (Atom)
Hi Dennis,
ReplyDeleteI'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,
Aleksandar
Thanks for your feedback, Aleksandar. We'll try to solve this in a different way
Delete@Aleksandar: Please try our new solution from http://dennisgaravsky.blogspot.com/2015/12/the-getobjectsnonreenterant-error-for.html
DeleteThanks for your time in advance!