What is a proper way to implement dynamic cached list?

sash_kr posted on Friday, October 18, 2013

"ProjectTracker" has a good example of cached list "RoleList".

But I would like to have something like dynamic list. What I mean?

Well, let's say we have cached list of employees. That list contains only actual employees. So, it doesn't contains employees which doesn't work already. But when I need to get some employee info from list that doesn't exists in that list, I would like somehow to append it to list.
What is a proper way to do it with CSLA?

I hope I explained it well :-)

skagen00 replied on Friday, October 18, 2013

I'm not sure I entirely understand, but I'll say this -

We do have cached user/employee lists ourselves and in many times in our read only lists we have a method to "append no selection option" (whether that's entirely proper or not, it works for us - we take our cached list, clone, and tweak it for the UI in certain circumstances). There's no reason why you wouldn't be able to provide a mechanism to include a method to append additional items to your cached list. If you do that - depending on how your cache works, you may or may not want to Clone() the list before you start monkeying with it as you won't necessarily want to reflect your cached list as having any "adjustments".

sash_kr replied on Saturday, October 19, 2013

Well, I thought about that. But I was not sure if that is right solution.

Now I have another question. Take a look on this method:

private void DataPortal_Fetch(int id)

{

  using (var ctx = MyProject.Dal.DalFactory.GetManager())

  {

    var dal = ctx.GetProvider<MyProject.Dal.IVacationDal>();

    var data = dal.Fetch(id);

    using (BypassPropertyChecks)

    {

      Id = data.Id;

      EmployeeId = data.EmployeeId;

      EmployeeName = EmployeeCachedList.GetList().GetName(data.EmployeeId);

      ...

    }

  }

}

"GetName" is a method where we 'append' our addition item.

Is this proper way to use dynamic cached list? I mean in DataPortal, on server side etc.

JonnyBee replied on Sunday, October 20, 2013

Hi,

The main challenge of cached lists is syncronization and making sure you have thread safe code. You may use the threadsafe collection available in .NET but the collection classes in CSLA are NOT theadsafe as the are based on BindingList or ObservableCollection.

For my own preference I would make the metods more like:

EmployeCachedList.GetList.GetItem(data.EmployeeId).Name;

sash_kr replied on Monday, October 21, 2013

"The main challenge of cached lists is syncronization"

This is probably what bothered me. Maybe you could explain it more detailed?

JonnyBee replied on Monday, October 21, 2013

Hi,

IE: It is difficult to make your code thread safe - especially if you need to add items dynamically.

Linq queries and foreach loops will throw exception if the collection is modified (items added or removed) on another thread during execution.

Recently the Immutable collections was released in .NET: Microsoft.Bcl.Immutable NuGet package.

http://blogs.msdn.com/b/dotnet/archive/2013/09/25/immutable-collections-ready-for-prime-time.aspx

While creating and running concurrently is easier than ever, one of the fundamental problems still exists: mutable shared state. Reading from multiple threads is typically very easy, but once the state needs to be updated, it gets a lot harder, especially in designs that require locking.

skagen00 replied on Monday, October 21, 2013

One thing I cannot recommend enough - if you cache a BO - if you have a static object on your server that is "cached" - make sure CanReadProperty returns true - override, and "return true" assuming your business rules allow it.

We cache a number of BOs and my colleague is very careful with us being thread-safe and minimizing such concerns - but the simple "CanReadProperty" override to just return "true" was something that took a server-crashing lockup issue we were having to being a non-issue. This same general concern happened to at least one other CSLA user in regards to CPU lockup.