CSLA .NET

Vibrant discussion about CSLA .NET and using the framework to build great business applications.

Forum has moved

New location: CSLA .NET forum


CSLA .NET Resources:
  • CSLA .NET forum
  • CSLA .NET home page
  • Csla.Xaml.ApplicationContextManager question

    rated by 0 users
    Answered (Not Verified) This post has 0 verified answers | 4 Replies | 2 Followers

    Top 500 Contributor
    37 Posts
    maxal posted on Tue, Nov 6 2012 12:04 PM

    In our WPF application users can log out and then log in into the system. With current implementation Csla.Xaml.ApplicationContextManager we sometime have interesting problem. I would like to check if anyone had the same problem before, or have any other comments. Here is the problem.

     

    ApplicationContextManager stores IPrincipal internally, and the value is shared between threads. That creates the problem in the following sequence of events.

    1. User pressed "Log off" button
    2. From the main thread we call DataPortal.BeginExecute method to do something, which creates Backgroundworker, new thread does not starts instantaneously, may take few milliseconds.
    3. From the main thread we do something like this:  ApplicationContext.User = UnAuthenticatedPrincipal, which changes the value of stored principal in ApplicationContextManager
    4. Now the background worker's thread is finally started, and SetThreadContext method is called, which changes the value of ApplicationContext.User again.

    I see some ways to address it, but interested to know how others do this and why.

    We are on 4.3.10.0

    Maxim Alexeyev Discovering.NET

    All Replies

    Top 10 Contributor
    2,279 Posts
    Suggested by JonnyBee

    So you start an async "Logoff" method that calls the DataPortal? 

    My best suggestion would be to add/alter the callback method and make sure to set
          ApplicationContext.User = UnAuthenticatedPrincipal,
    in the callback.

    Sometimes the User object is stored in each thread and the DataPortal is unaware of how the ApplicationContextManager handles this so I would be very hesitant to change this behavior in the framework.

    Jonny Bekkum, Norway CslaContrib Coordinator

    Top 500 Contributor
    37 Posts
    maxal replied on Tue, Nov 6 2012 1:16 PM

    Not exactly. The logoff is NOT an async operation. I can logoff immediately and reflect this in UI, which I do.

    Theare are couple commands I call before the logging using BeginExecute method. And I use the fact that DataPortal BeginExecute actually grabs some infromation from application context before logoff is done. Examle: save some user settings, layouts, log statistics etc. Those are completely independent, and I don't really need or want to syncrhonize them.

    I also don't want to wait for them to be executed to complete logging off in UI. We are working with remote app server (over internet), so it can take some time.

    Your soultion is valid though, thank you for the response.

    Maxim Alexeyev Discovering.NET
    Top 10 Contributor
    9,475 Posts

    I hate to say it, but this is a "feature" :)

    The User property is stored in a static field to overcome the sad fact that WPF makes it nearly impossible to change the principal once the app is running. They really did not think through an app scenario where the user logs on and off the app without closing the app between users...

    The BackgroundWorker copies the main thread's context into the background thread because in non-WPF scenarios that is the only way to get the context and principal to flow automatically onto the background thread.

    I suppose it could be argued that the BackgroundWorker shouldn't copy the User property in a WPF app because the value is already universal. However, even that change wouldn't fix your problem, it would just trade one race condition for another...

    Rocky

    Top 500 Contributor
    37 Posts
    maxal replied on Wed, Nov 7 2012 8:53 AM

    Thank you Rocky. Can you elaborate what did you mean by " WPF makes it nearly impossible to change the principal once the app is running"?

    Assuming I figure out how to workaround problem with async calls, do you envision more problems with changing principal?

    Maxim Alexeyev Discovering.NET
    Page 1 of 1 (5 items) | RSS

    Copyright (c) 2006-2014 Marimer LLC. All rights reserved.
    Email admin@lhotka.net for support.
    Powered by Community Server (Non-Commercial Edition), by Telligent Systems