In our application, we have a service that writes a very large amount of data to the database. This generates more than 1 million inserts into the database.
I’ve now optimized this service so that it completes in about 100 seconds. I disabled transactions for the UnitOfWork to avoid additional overhead (isTransactional: false). The data is now stored in the database after just under 2 minutes.
Problem: Completing the UoW (uow.CompleteAsync()) takes about 17 hours !!!
Since I don’t see any log messages, I have no idea what’s taking so long. My guess is that events are being generated (which are completely unnecessary in my case).
The affected entities are not auditable. I also added a [DisableAuditing] attribute to the AppService methods.
I’ve now moved the service call to a background job so that it doesn’t block anything. But it’s still very unsatisfying this way.
What can be done to optimize this?
protected override async Task ExecuteWithContextAsync(InstallationJobArgs args)
{
await _jobStatusStore.SetRunningAsync(args.JobId);
try
{
var data = await LoadDataAsync(args);
using var uow = _unitOfWorkManager.Begin(requiresNew: true, isTransactional: false);
await _installer.InstallAsync(data); // Takes 100 seconds
await uow.CompleteAsync(); // Takes 17 hours
await _jobStatusStore.SetSucceededAsync(args.JobId);
}
catch (Exception ex)
{
await _jobStatusStore.SetFailedAsync(args.JobId, ex.Message);
throw;
}
}
We have a very large project with many entities. If we define a separate namespace for each entity, then working in Visual Studio becomes very cumbersome due to the large number of folders (since classes are stored in a folder for each namespace).
That’s why we’ve grouped related entities into the same namespace. However, this results in a large number of classes in the same folder for Domain and Contracts, which makes things chaotic again. We therefore manually move the classes into subfolders.
It would be great if the Suite allowed you to define the folder where the entity is generated.
That way, we could organize the classes hierarchically.
We have some entities without string properties. If you want to create a NavigationProperty for such an entity, unfortunately this isn’t straightforward, since you have to select a property as a “display property,” which must be a string.
Our workaround was to specify ConcurrencyStamp as the display property. But that can’t be a solution. If we could at least use the ID (GUID), that would be fine... but then we get compile errors.
Since we don’t generate the UI, we don’t need the part with the lookup methods (that’s where the compile errors occur) or UI Pick Type at all.
Could you please adjust this so that we can do without the display property or reference something other than a string?
Okay, I have now recreated the scenario and attempted to reproduce the issue. However, it has now worked as intended and no entries were deleted from the database. I suspect that during my initial test, I made the change directly in the database and the cache had not yet been synchronized before I made the next change in the application.
Thanks for your help.
Unfortunately, we are unable to update at this time. Therefore, I would appreciate a response regarding how the framework behaves (in version 8.3.4). You may also simply confirm whether my following statements are correct or not.
However, my last two questions have nothing to do with the cache.
What can you say about that?
I have also identified a second problem. When I change the features of the assigned edition, the individual value of the tenant is deleted from the database and the value of the edition is applied.
It is very dangerous that settings are lost... is this the desired behavior?
Ok, thank you.
I now have the following problem:
Are no feature values of the edition applied as soon as a value is “overwritten” on the tenant?
I assumed that only this value (Identity.MaxUserCount) differs from the values of the edition?
So you don't know how long the entries in the cache are valid by default?
I don't want to implement a special function for this individual case. If I did, I would have to override the standard behavior so that the field is not deactivated in the features on the tenant.
Are there any other ways to force synchronization (e.g., restarting the app)? Or does this happen regularly in the background as a job?
