locked
Cache accessed from multiple executables RRS feed

  • Question

  • I have a situation where I need to share cached data between multiple winform executables. They operate in series. ExeA runs, and manipulates the data, then ExeB runs and manipulates the same data (or tries to).  The problem comes about when the process starts over. ExeA creates a new data object stores it into the cache, however when ExeB starts up and gets this object out of the cache, it is the object it had manipulated from the 1st run. EX:

    Start:

    1) ExeA creates a new Class Foo. Manipulates Foo, adds data to it.
    2) ExeB gets Foo from the cache, works with the data. Saves it to the cache every so often while working on it.

    Process starts over

    3) ExeA creates a new Class Foo. Manipulates Foo, adds data to it.
    4) ExeB gets Foo from the cache. However, this is the Foo it was working with in step 2.

     

    Why does ExeB seem to be getting a version that is its own? I tried using regions as well thinking maybe the caching code was making some kind of pseudo regions based upon AppDomain, but that did not help either. How can I get ExeB to be pulling the latest version of the cached Foo from the cache?

     

    P.S. Don't suggest a new design, the app has to work this way. I am writing an IVR application, and the IVR software is a control that has to run on a windows form. Lastly I have to save to the cache from the same executable because the form handles more than one call, so I have to retrieve that lines call information during call events.


    //Will write code for food
    Tuesday, June 14, 2011 4:31 PM

Answers

All replies

  • Actually the 1st time I run it ExeB gets a null item from the cache. Causing an exception. Then I start the process again, and this time ExeB is able to retrieve a Foo. So the actual flow looks similar to:

    1) ExeA creates a new Class Foo. Manipulates Foo, adds data to it.
    2) ExeB gets Foo from the cache. Foo is Null, exceptions is thrown.

    Process starts over

    3) ExeA creates a new Class Foo. Manipulates Foo, adds data to it.
    4) ExeB gets Foo from the cache, works with the data. Saves it to the cache every so often while working on it.

    Process starts over

    5) ExeA creates a new Class Foo. Manipulates Foo, adds data to it.
    6) ExeB gets Foo from the cache. However, this is the Foo it was working with in step 4.

     

    In step 6 I am expecting to get the brand new created foo that step 5 created. Yet I am not. Not sure why.


    //Will write code for food
    Tuesday, June 14, 2011 7:04 PM
  • Hi Tim,

    Are you using Caching Service (Windows Azure AppFabric) and not Windows Server AppFabric caching? For Windows Server AppFabric caching question, we should ask in the this forum (AppFabric Caching).

    For Azure Appfabric Caching Service, it is shared by all clients. That means no matter it is called by ExeA, ExeB or an web application, they will get the same result. Please refer to How to: Configure a Cache Client Programmatically (Windows Azure AppFabric) to write a client to access Azure Caching Service.

    If you see a different behavior as I described, could you please share a sample code so that I can reproduce the bahavior on my side?

    Thanks,


    Wengchao Zeng
    Please mark the replies as answers if they help or unmark if not.
    If you have any feedback about my replies, please contact msdnmg@microsoft.com.
    Microsoft One Code Framework
    • Marked as answer by Wenchao Zeng Thursday, June 16, 2011 10:28 AM
    • Unmarked as answer by Wenchao Zeng Thursday, June 16, 2011 10:28 AM
    • Marked as answer by Wenchao Zeng Tuesday, June 21, 2011 5:33 AM
    • Unmarked as answer by Wenchao Zeng Tuesday, June 21, 2011 5:33 AM
    Wednesday, June 15, 2011 7:28 AM
  • I am using hosted (AppFabric Caching).  I moved the question here: http://social.msdn.microsoft.com/Forums/en-CA/velocity/thread/f92ae0e1-5d4a-4a83-bd2f-c869fdeaf8e9

     

    Sorry I thought this was the appropriate forum.


    //Will write code for food

    Wednesday, June 15, 2011 4:36 PM