I use an RKObjectManager to load objects from a remote resource, and, use a tableView to display the fetched objects. When my tableView model is deallocated I cancel all current requests with
[self.objectManager cancelAllObjectRequestOperationsWithMethod:RKRequestMethodGET matchingPathPattern:self.resourcePath];
When the user reloads the view, a new model is created - Instead of creating the objectManager from scratch, I fetch the same one (I store the objectManager instance elsewhere). I'm trying to use a single object manager across the app for the same service/site - not sure if we can use multiple object managers against the same persistent object store? However, now all requests to the resource path fails with the following error.
restkit.network:RKObjectRequestOperation.m:569 Object request failed: Underlying HTTP request operation failed with error: Error Domain=NSURLErrorDomain Code=-999 "The operation couldn’t be completed. (NSURLErrorDomain error -999.)"
It looks like once I cancel against a resource path on an objectManager, I can't reload that resource via a fresh request at a later point in time. What would the best practice be to cancel current requests and reload later? In the earlier delegates version of restkit, my app would crash if I didn't remove my model/view as delegate from the object manager. I'm thinking I should still cancel my requests to avoid such issues even with the new blocks way of operation? Pointers/advice much appreciated. Thanks
Regards
George M.P.
not sure if we can use multiple object managers against the same persistent object store?
No problem with that.
When the user reloads the view, a new model is created - Instead of creating the objectManager from scratch, I fetch the same one...
If you create a new model (I guess you mean managed object store?) you should probably create a new object manager to go with it. In theory you can give the old object manager the new store but there is (or could be) a lot of internal caching that could be invalidated.
Cancelling and then reloading later should be fine, the question is what you're doing with the object store in between...
Related
In the _Layout.cshtml, the #Html.MvcSiteMap().Menu("viewname") caused extra 2s in each request. I found that the repository's constructor being executed several times depends on the menu's count so I guess this might be where the extra 2 seconds cames from.
Is there a way to prevent the constructors be executed once the menu rendered?
I suspect the reason for this is because you are using Security Trimming. In order to determine whether each link has access, MVCSiteMapProvider creates and releases an instance of each controller for each action. The only way to avoid this is to disable security trimming.
With security trimming enabled, it is not recommended to have any heavy processing within your constructors, as this will negatively affect performance. You should defer any processing (such as opening database connections) to later on in the request lifecycle by using an Abstract Factory to create the connection and injecting the factory into your constructor instead of the dbcontext/connection object. See this post for an example.
That said, the AuthorizeAttributeAclModule is not as efficient as it could be because when you have controllers with a lot of action methods, the same controller instance could be reused instead of creating one for each action method. You could make a custom AuthorizeAttributeAclModule and use the HttpContext.Items dictionary to request-cache each controller so they are reused instead of re-instatiated. You will need to do some refactoring to do it, though. The controller is created on line 235 and it is released on line 108. You need to make sure that the release isn't called until the after very last node is checked. You can do this by creating an IActionFilter to release them after the action is complete, but it means that action method will need to know about the same request cache (in HttpContext.Items) as the AuthorizeAttributeAclModule. You just need to implement the OnActionExecuted method to clean up the controllers from the request cache.
I'm new with AppFabric Server caching but after playing around with it everything has been working like a dream.
I can add for example datatables to my cache and get that back to use just fine.
I got exited about this functionality and tried to test this with one 3rd party vendors dll that includes login session data (session id, date's etc.)
I created WCF service with method where you consume this dll to login and I store that session to my cache.
This works just fine and I can verify this by looking at statistics of my cache with PowerShell.
Then I created another method that is supposed to pick up this cached session and use it to execute actions. This is where I'm running to the wall.
I can see that I have been able to get session from cache, but information within session object is null (session id, date's...)
I've been serching help for this from everywhere but nobody seams to face this issue.
So my question is
Can AppFabric server cache ALL field values of given object (Public/Non-public not having any role)?
Is there any way to see actual existing content of cache where you would see keys and cached objects with values?
Thanks for all possible comments!
Regards
Mikko
In AppFabric you can only cache objects that are serialisable (or serializable for US readers :-) ). The fact that you have been able to store your session objects in the cache suggests that they are indeed serialisable. But to figure out what's going on here we'll need to probe a little deeper.
By default with binary serialisation, all fields/properties of an object are serialised, public and private (whereas XML serialisation only picks up the public values). We aren't told which flavour of serialisation AppFabric uses, but binary serialisation tends to be more efficient so it's a reasonable assumption that that's what gets used under the covers. However, it's possible to override the serialisation behaviour using the NonSerialized attribute, so that items marked NonSerialized don't make it into the serialised version of the object. The MSDN page for Selective Serialisation specifically advises that security-sensitive information should be marked as nonserializable.
A session ID definitely comes under the heading of security-sensitive information as it's key for session hijacking, so I should say that's the problem you're facing. You could confirm this by having a look inside the 3rd party DLL with ILDasm or Reflector to see if the fields inside the session class are indeed marked as not serialised.
Can you get round this? Well there is, of course, nothing to stop you creating your own Session class that you populate from the 3rd party's object where you keep all the properties serialisable and caching that instead. Bear in mind, however, that you're then essentially doing the very thing they've tried to stop you doing...
I have used Core Data just creating projects with "Use Core Data" checked, using the code that XCode creates by default and, if necessary, adding or modifying just a few things.
Now I have a "main" app and I have created a helper app (status bar item app, LSUIElement = 1 and Login item). The helper app is Build as main app target dependency and copied into the main app "Resources" folder.
When the status bar icon is clicked the helper app shows a window to the user to collect some info to create a new managed object according to the main app Core Data Model.
But, how can I create a new managed object from the helper app for the main app?
By now I´m thinking to:
check if main app is open or not (I don´t know if it´s possible)
if it´s open, let the main app to perfom a selector with a dictionary with the info sent from helper app (I don´t know if it´s possible)
if it´s close then (in the helper app) create a persistent store coordinator, manage object model and manage object context using the model and persistent store files from main app. Create the new managed object. And I don´t know if it´s better to terminate MOC, MOM and PSC each time the user creates a new MO to avoid conflicts when main app opens or it´s not optimal and could affect performance...
It´s a good approach? Any point to start? Thanks in advance
Do you have to create a managed object? If you're just collecting simple data in the helper app it would be much simpler to pass that input to the main app via the userinfo dictionary in a Distributed Notification. Then the main app could create the managed object and you don't have to deal with merging changes between the two contexts.
Otherwise you'd have to pass the helper app a path to your MOM, create a MOC in the helper app, create the object, save the MOC while notifying the main app to merge changes by passing the IDs of the changed objects, reloading your main app's model objects, and so on. I've gotten it to work, but it's a huge headache and prone to errors. I'd avoid that route if possible.
Edit: I just realized you want to be able to write to your main app's store even if it's not running. It sounds like you need to re-think this before writing any code. If the helper app executes on its own, it's not really a helper app. Could you go into more detail about what you're actually trying to accomplish? This kind of hackery is not really a good idea and could lead to data corruption.
I am looking for an example of how to use the new DataServiceState Save and Restore methods in a WP7 application in order to tombstone a datacontext - I cannot find any examples and the approach I used resulted in an exception
this saves the data context correctly
PhoneApplicationService.Current.State["DataContext"] = DataServiceState.Save(this.Model.Entities);
this attempts to restore it after the app is re-activated
var dc = (PhoneApplicationService.Current.State["DataContext"] as DataServiceState).Restore();
but throws an exception
An item could not be added to the collection. When items in a DataServiceCollection are tracked by the DataServiceContext, new items cannot be added before items have been loaded into the collection.
This is the same exception I get if I try to reload a datacontext that I stored "directly" (without using the DataServiceState.Save method) in the PhoneApplicationService.Current.State. I cannot find any offical documentation on the new ODATA v2 DataServiceState class or examples.
thanks
Michael
I am looking for an example of how to use the new DataServiceState Save and Restore methods in a WP7 application in order to tombstone a datacontext
Are you sure? First link - bottom of the page.
Have you tried the walkthrough here?
How to: Preserve and Restore Application State for Windows Phone
Storing and retrieving datacontext is tricky due to serialization and object reference issues. The MSFT team is working on improving DataServiceState. I've succeeded in saving and restoring the context in a WP7 app, by storing the DataServiceState returned by Save() in the app state (just like you've done). Then on activated, I first instantiate my DataServiceClient (which contains the context and the DataServiceCollection), and then I call a RestoreData method in the client and pass the retrieved DataServiceState to it. The method restores the context and DSC within the DataServiceClient.
I'm looking at using Subsonic with a multi-tenant ASP.net web application. There are multiple DB's (one per client/instance). The user logs in with a domain suffix to their username (e.g. user#tenant1, user#tenant2).
The custom membership provider will then determine which database a user is using, and authenticate against it. All user-initiated calls in the webapp will be wrapped in a SharedDbConnectionScope call, however I have a question regarding caching subsonic items.
Basically each instance will have a few records that rarely change (search options/configurations). I would like to read these in the Application_Start event, and cache them into the ApplicationState.
In the Application_Start event, it would loop over each client database, use a SharedDbConnectionScope to connect to each DB, and create these cached records (e.g. Application('tenant1_search_obj') = subsonic_object
When a user loads the search page, it would then check what domain a user is in, and then retreive that search option from the cache.
Is this feasible? I'm just concerned that if I cache an object, when I retrieve it from the application cache it won't know what connection its using, and might possibly pull in the wrong data.
I'd like to avoid putting this in the session object if possible.
it's possible, but probably not a good idea since it doesn't scale at all - you're going to pop a new connection for every single client whether they show up or not.
Maybe your best bet is to "lazy load" the setting - first hit on the search page loads the config into the cache or Application settings and there it stays.
Other than that - to answer your question it is possible. If you're using SubSonic 3, just create a new provider on the fly using ProviderFactory.GetProvider(connectionString, "System.Data.SqlClient") and then execute your stuff against it.
For SubSonic 2 - SharedConnectionScope is what you want.