I'm using MEF (the one in .Net Framework, not System.Composition Nuget) to do DI in asp.net. I'm encountering memory leaks like many have previously due to MEF rooting NonShared IDisposable (e.g. link)
I'm looking at using child containers to rectify this by having
Child containers create (NonShared) parts specific to a single request
Parent container (referenced as an export provider) containing the shared parts
So something like:
CompositionContainer GetRequestContainer(CompositionContainer parent, ComposablePartCatalog catalog)
{
return new CompositionContainer(catalog, parent);
}
Originally, I built a single catalog with Shared and Non-Shared parts: To create a child container with only NonShared parts I used FilteredCatalogs built off the parent CompositionContainer's catalog so that the filtered catalog contains only the NonShared parts.
This resolved the memory leak since I could Dispose() the child container at the end of a request whcih would then free up all my NonShared IDisposable objects. Great.
However, calling childContainer.GetExportValues returns duplicates because there are parts from the parent containers catalog as well as the child container's catalog.
Now I want to create 2 catalogs explicitly:
Global catalog for all shared parts
Local catalog for all NonShared parts
I suspect the IDisposable tracking is at the container level so I should be safe passing around single instance of each catalog, but that is what I wanted to ask here and confirm:
Is it threadsafe to have a single instance of a catalog backing all instances of containers?
So N concurrent WebRequest instances are serviced by N + 1 CompositionContainer instances (child+parent), all backed by 2 global catalog instances.
CompositionContainer parent = new CompositionContainer(Static.Global, CompositionOptions.IsThreadSafe);
CompositionContainer GetRequestContainer(CompositionContainer parent)
{
return new CompositionContainer(Static.Local, parent);
}
It is perfectly safe to use the same catalog instance with several CompositionContainer instances (by the way, this is true regardless of whether you use the CompositionOptions.IsThreadSafe option when creating your container).
The reason it's safe to do so is because the catalog merely defines the "potential" of parts that can be created by the container, and doesn't hold any data regarding whether they have been instantiated or not. It's the container's responsibility to track such things.
Related
We have the following concept in our application (composed of a UI and a REST backend):
Container is-a-parent-of lineItems
a lineItem cannot be created without having a valid Container and both of these entities are persisted in DB via spring data.
The UI lists the lineItems in two pages
list view: the lineItems of a single Container are displayed
search page: the lineItems of different Containers are displayed
We have a single source of data for both of these UI pages. The data comes from a common REST backend which returns a list of lineItems wrapped in a POJOview object (along with other information) - current state.
Change needed - On the search page, now, we need to show some information from the Container of a lineItem. So, now we need to make available the data of a Container associated with a lineItem on the search page. We are currently discussing two possible approaches for doing it:
Approach 1:
POJOview {
List<LineItem>
List<Container>
}
This approach avoids implementation of a wrong concept(described below) which gets implemented in approach 2.
List<LineItem> and List<Container> are sent separately, so, less data gets transferred to the UI. If 20 lineItems belonging to 1 Container are sent, then there is only one object of the Container as compared to 20 Objects of Container in approach 2.
The code is easier to understand and maintain
A disadvantage is that it requires some extra logic in the search page for the UI to map the lineItem to its Container in the other list
Approach 2:
POJOview {
List<LineItem> //insert Container of a lineItem as a member variable in the lineItem itself. Container instance is annotated with #Transient to avoid persistence in DB.
}
This approach implements a wrong concept in the backend in the sense that lineItem now contains the Container which is opposite of the domain concept (Container is-a-parent-of lineItems) and hence it is not intuitive and makes the code difficult to understand and maintain.
Each lineItem now contains Container, so, if we have 20 lineItems on the page belonging to the same Container, then the Container data which is now a part of lineItem gets loaded 20 times (performance hit)
This has an advantage of a quick fix
The problem is that despite all these facts, my colleague still maintains that Approach 2 is the optimal way since it is a quick fix and he sees nothing wrong in it. Am I missing something here?
As per my opinion, one of the good ways to implement would be as below:
The REST service can return data in following format:
a) A list of LineItem objects where each LineItem object contains just the ID of its container (note: it is not a wrong approach because the child objects can very well contain the reference to its parent as long as the parent data is not repeated in every child).
b) A list of container objects. Obviously only those containers should be returned that are referenced by the line items.
The front end logic can go over the list of line items and look up the container details in the container list.
The data items a) and b) can be sent via separate calls or a single call. Ideally if the REST principles are to be followed strictly and making two calls is not impacting performance, then two separate calls should be made and thus as per the REST principles LineItem Resource is retrieved in one call and Container Resource in another call.
By using this approach, the container information is not repeated, only the container IDs are repeated in the line item objects which should be okay in most cases.
Thus this approach is essentially similar to Approach 1) that you have described except for the fact that lineitems can contain the ID of their parents (container).
As per what I understand, Approach 2 mentioned in the question repeats the full container information for each lineitem object which is definitely wrong. Ids can be repeated but not the full object whether the data is being retrieved from DB or being passed around in the backend or is being sent to front end.
Hope this provides some clarity.
According to StructureMap's documentation the default behavior of containers is that a Parent Container resolves a new object instance each time one is requested and Nested Containers resolve the same object instance.
In 99% of cases this is fine - however I'm keen to know if there's a way I can set a nested container to behave similarly to the Parent Container and resolve new object instances by default - without the need to rely on the .AlwaysUnique() method.
Is this possible or is .AlwaysUnique the only way to do it on an object by object basis?
I think that beside explicit specification of nested container configuration there is no support for that as it was designed around creating temporary context for objects resolution. IIRC in SM 3.0 HttpContextScoped lifecycle was implemented with usage of nested container.
If you want to have the flexibility of resolving existing object from the container or creating a new one you can implement factory that would handle it for you through injected context into the factory or based on explicit method call (factory.Create() or factory.ReuseIfExistsOrCreate()).
Hope this helps!
I'm converting a legacy workflow system to WF4 so I have to jump through a couple hoops to make it match up with the api of our application. So I'll try to keep the problem explination as simple as possible. :)
I have a custom activity that takes a sequence as an argument and then executes it. Prior to executing it, the custom activity needs to traverse the sequence (and it's branches etc) looking for specific types of child activities - then it does some reporting on these specific child activities.
I know it is possible to traverse the child sub tree of an activity during Validation time when a Constraint can use a GetChildSubtree activiy, but this doesn't give me access to the list at runtime. I also know it's also possible to execute a similar call using ActivityValidationServices from the host application, but that won't work for my scenario either.
So what's the best way to get a list of the activities in the child subtree from within the execution method of a custom activity.?
Thanks in advance!
Marcus.
You might want to take a look at WorkflowInspectionServices class which provides methods for working with the runtime metadata for an activity tree. In particular the GetActivities method.
GetActivities returns all the direct children of an activity, including activities, delegate handlers, variable defaults, and argument expressions. You can now write an extension method to return all activities including the inner branches:
public static IEnumerable<Activity> GetInnerActivities(this Activity activity)
{
var children = WorkflowInspectionServices.GetActivities(activity);
foreach (var child in children)
{
children = children.Concat(child.GetChildren());
}
return children;
}
Now get all activity's inner activities of a specified type:
activity.GetInnerActivities().OfType<MySpecificType>();
How can i access a variable or change the state of an element(like tabNavigator) from one mxml to another mxml in FLEX 4.6??
Each separate MXML file should be viewed as a class, since that is what they are.
In the theory of encapsulation; two classes should not directly access / change each others variables or state. They should use an API provided by the developer of the MXML Class.
If MXML 1 is the parent of MXML 2; then MXML1 can pass data to MXML2 by setting public properties or calling public methods.
MXML2 can pass data to MXML1 by dispatching events.
If MXML1 and MXML2 are not in a parent child relationship; (AKA Both children of the same component as one example) they they should not communicate with each other directly. They should dispatch events which the mutual parent should handle and use to set values or execute methods on it's own children.
From an encapsulation standpoint, that is how it should be done using the built in facilities of ActionScript / Flex.
What a lot of people do as part of building applications is to make use of dependency injection. That was values that are "global to the application" can be shared among multiple components. Another approach to doing this is to use a Singleton. A third approach might be to make use of static values on a class; which can be accessed without accessing an instance of a class.
I've got a number of modules in a Prism application which load data that takes 3-8 seconds to get from a service.
I would like to be able to say in my bootstrapper something like this:
PSEUDO-CODE:
Customers allCustomers = Preloader(Models.GetAllCustomers);
And this would run in a background thread and when the user actually needs the variable "allCustomers" it would be fully loaded.
Is there an automatic service in Prism/Unity which does this type of preloading?
No, there is not.
However...
What you can consider is adding your ViewModel with a ContainerControlledLifetime to the container in your ConfigureContainer method that the views can use. You'd kickoff your threaded request in the constructor of your ViewModel and allow Views to pull this ViewModel out of the Container.
Even if they grab the ViewModel out of the container before the GetAllCustomers method is done firing, they will be notified correctly if the property you store the customers in implements INotifyPropertyChanged correctly.
If it was more appropriate, you could also do this from the Modules (in the Initialize method), rather than in the bootstrapper (for instance, if your Module was what actually knew about your Customer's Model).