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

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.

 

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...

 

 

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).

 

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.

 

 

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...