Evict multiple objects

[Wolfgang]

We have the situation that mutliple objects are evicted and refreshed.

The problem is that is takes some time with >60.000 objects.

At the moment we do a 

foreach( var item in list)
{
 objectScope.Evict(item);
 objectScope.Refresh(item);
}

Is there a possibility to say: evict all items fro list and refresh them afterwards?

[Thomas]

Hi Wolfgang,

with this amount of data, it is usually much better to perform the query again, because otherwise you can easily end up with a large number of database calls fetching single objects.
In case you don't have modified objects in the ObjectScope that you want to keep (besides the large number that you want to refresh) you should be able to just rollback the object scope, because at any Begin() or the scope Transaction, we will refresh the first level cache (the ObjectScope). If you used the second level cache too, you will need to evict the objects from it via one of the scope.Database.Cache.Evict methods.

Regards,
Thomas
Telerik

 

 

[Wolfgang]

Hi Thomas,

In  dirty objects are evicted. For some situations we already use scope.Database.Cache.EvictAll()
(our method to start a transaction looks like scope.db.Cache.EvictAll; scope.Transaction.Begin )

We have multiple objectscopes (and multiple processes). A central component gets all dirty objects and notified other dialogs or processes with the changes.
On Commit we dotherefore
Get a list of all dirty objects.
Create intermediate information objects what has changed
Do a commit - if(scope.Transaction.isActive) scope.Transaction.Commit();
And afterwards Evict every dirty object from the list.

The intermediate objects are then used to inform all other dialogs/objectscopes/programs that something has changed.

At some situations the list of dirtyobjects is huge (for example deleting an object which has many follow up objects to delete).

As commit is already done would it be save to just use: 
if(scope.Transaction.isActive){scope.Transaction.Commit();scope.Transaction.Begin();}  DevExpr. elements are bound to scopes)

Best regards,
Wolfgang

[Thomas]

Hello Wolfgang,

reading through this I thought: Why is it that you have so huge lists of dirty objects that you need to evict manually? I'm asking this because our code will make sure that all dirty objects that get stored in the database are evicted from the second level cache. If you are using multiple processes you need to combine the different second level caches into a cache cluster using our MSMQ implementation, but this should take care and get rid of the bulk of the manual evict messages. So: Maybe this is work that you could avoid because it will already have been done for you.

Of course, this holds only true if the instances are physically modified; if your instances must not longer be cached due to a logical change, then this would still require manual evictions. But maybe you could also perform the evictions in one transaction scope transaction (so they get done together) and additionally do either forget about the Refresh (do you really use all of the refreshed objects?) or do the refresh in a more efficient way (because I suspect this will be where the time is spent). Could you evaluate where the time is actually consumed?

Regards,
Thomas
Telerik

 

 

[Wolfgang]

Hello Thomas,

There are multiple reasons for large lists of dirty objects.
We have a production system which can plan future productions. With this a large list of objects (single production jobs) are created which then will be deleted after production (which can be immidiatly, or the production will be done in a few days).   

The production jobs will be displayed in another process. The executalbe with the production window can run on the same system. Or on a distinct one. So if anyone deletes a complete production tree in a planning window it needs to be also deleted in the production window.

The refresh of the Gridview displaying the items is minimized (only rows which are visible get refreshed) - but if objects are added or deleted the grid will also need to have knowledge about what is deleted.

We are not using one objectscope but multiple ones. The most "windows" can be also started as standalone component.One central component informs all objectscopes and grids about changes. (With only one scope we had large problems as the background planning job and windows can do commits at the same time. If we encapsulated transactions the background and foreground jobs were sometimes mostly waiting for a lock, and we have seen situations were a grid then dies).

Its not only about processes on the same computer, it can also be different databases on different sites. ). Think about central planning at one site, and production on different other sites (plannign is maybe a bad example as it can also be done at same site, but as objects belong together and statistic objects will also be produced it is safer to have complete object trees instead of having objects with missing informations on one system and corresponding informations on another one).

Regards,
Wolfgang

 

 

  

[Thomas]

Hi Wolfgang,

I meanwhile think that the issue is not with the evict, but with the refresh. The refresh will go to the database and fetch the objects current state into memory. With large lists, these calls can add up in time. The question is: Do you really need to refresh all the evicted items? First you are telling the object scope to 'unknow-in-memory' the instance, and then you are trying to load the newest state. Maybe the evict on the scope level is then not needed (or only for those instances that got deleted in the database).
If the issue can be related to a mass refresh, some code changes (on our side) could be needed to better handle this situation.

Regards,
Thomas
Telerik

 

 

[Wolfgang]

Sorry, longer .. let's say vacation. I think the problem is the need for the mass refresh. The problem is the mass data which can be changed by one userclick.

[Thomas]

Hello Wolfgang,

mass loads are always difficult, because you need to minimize the number of SQL calls. Sometimes it is faster to execute a query again instead of trying to refresh the result from the last query execution.

Regards,
Thomas
Telerik