Print Page | Close Window

SaveChanges in IEntityLoginManager.Logout

Printed From: IdeaBlade
Category: DevForce
Forum Name: DevForce 2010
Forum Discription: For .NET 4.0
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=1779
Printed Date: 15-Oct-2026 at 2:52pm


Topic: SaveChanges in IEntityLoginManager.Logout
Posted By: stephenmcd1
Subject: SaveChanges in IEntityLoginManager.Logout
Date Posted: 04-May-2010 at 10:44am
After upgrading to DevForce2010, we are running into problems calling SaveChanges in our custom implementation of IEntityLoginManager.Logout.  The error we get is: "SaveChanges cannot be called from within a Server-hosted EntityManager." 
 
In DevForce2009, this kind of code worked fine:
 
/// <summary>
/// Logs out the current user.
/// </summary>
/// <param name="principal">The currently logged on user.</param>
/// <param name="entityManager">A server-side <see cref="EntityManager"/></param>
public void Logout(IPrincipal principal, EntityManager entityManager)
{
    //Get our domain-specific EntityManager
    var em = new DataModelEntityManager(entityManager);

    // ... clean up after the user ...


    //Save the changes
    em.SaveChanges();
}
 
Is there some different way that we should be doing this kind of thing in DF2010?  It would seem like overkill to new up a completely different EntityManger, connect/login/etc., just to be able to do some DB work on logout.  I guess another option would be to fire off a Stored Procedure that does this clean up....although Stored Procedures don't work in this version...


Replies:
Posted By: ting
Date Posted: 05-May-2010 at 6:38pm
We ran into some re-entrancy issues, so you currently cannot save within this context.  We are planning to change it and enable this (or similar) functionality again though.
 
Aside from that particular issue, it may make more sense to trigger the cleanup client-side before logging out, either using the client-side EntityManager to save changes or using an InvokeServerMethod.
 

Posted By: stephenmcd1
Date Posted: 06-May-2010 at 2:13pm
Thanks for the reply.  That makes sense.  When you say that you're "planning" to fix this, do you have any kind of time frame?  Is it going to be in the next release or just some future release sometime?
 
There are certainly some workarounds to this issue.  I don't really want to rely on the client initiating the cleanup...thereby making a two-step logout process.  The cleanup that my IEntityLoginManager.Logout method is doing is because of things I do in IEntityLoginManager.Login.  So I don't want to expose this kind of implementation details to my client.  Plus, calling Logout is something we do as a kind of "last ditch" effort if we detect the browser hosting our Silverlight client is closing.  In this case, it's nice to know that, if we can at least fire off the logout message, the cleanup will happen (as opposed to firing off a "Cleanup" call, waiting for that to finish, and then calling Logoff).

Posted By: ting
Date Posted: 07-May-2010 at 6:14pm
I don't think it will make the upcoming release, so probably the release after that.  Sorry for the inconvenience!

Posted By: ting
Date Posted: 17-May-2010 at 2:16pm
I just confirmed that this has been fixed and will make the next release (early June).

Posted By: stephenmcd1
Date Posted: 30-Jun-2010 at 4:17pm
Testing with the latest version shows that we are now able to call SaveChanges from IEntityLoginManager.Logout - so that's good.  However, we've run into some related problems.  We have a custom EntityServerSaveInterceptor that checks the Principal property to make sure the user is allowed to save data.  In all other places, this works fine but when it's triggered by a call to SaveChanges() in Logout, I can't seem to find the logged in Principal so my Interceptor ends up canceling the request (it assumes the request is malicious).  The Principle gets passed correctly as a parameter to IEntityLoginManager.Logout but surprisingly the Principle property on the passed in EntityManager is NULL and the Thread.CurrentPrincipal is some GenericPrincipal - not what I would expect.  In the Interceptor, the Principal the same GenericPrincipal and the EntityManager.Principal is NULL (still). 

Is this a bug or am I missing something?  Thanks.

Posted By: ting
Date Posted: 01-Jul-2010 at 5:03pm
Nice use case. ;)  The EntityManager is already considered "logged out" by the time it hits the EntityServerSaveInterceptor.  We're investigating the best way to handle this in our code so that this will work.
 
If you don't want to move the SaveChanges() code, you could workaround this by creating a ConcurrentDictionary with the thread ID as the key, to pass information from IEntityLoginManager.Logout to the EntityServerSaveInterceptor.  Very hackish though...
 

Posted By: stephenmcd1
Date Posted: 01-Jul-2010 at 5:39pm

I can do that hack for now.  Do you have an estimate when this will work without a hack?  Next release?  Some distant future release?

My backup plan was to use the EntityManager.Tag property to stuff some data in (to easily communicate between the LoginManager and the Interceptor) but that didn't work.  It appears the EntityManager provided to the Interceptor is a different EntityManger (so the Tag property is always null in the interceptor).  Is this the desired behavior?  I guess it makes sense (especially when I consider client-side queries, etc.) but I just want to make sure.

Posted By: stephenmcd1
Date Posted: 27-Jul-2011 at 11:14am
Has there been any update on this.  The temporary workarounds that we've been doing to get around this issue are starting to get more complicated and fragile.  It would be really nice if the Thread.CurrentPrincipal, EntityServerSave/QueryInterceptor.Principal, etc.  had the correct value - that is, the user that is getting logged off.  We're starting to do more things in the IEntityLoginManager.Logout method and we're hitting some walls because of this issue.

Thanks,
-Stephen


Print Page | Close Window