Alex (Xtensive) wrote:

A lot depends on expectations: if it's enough to have s single Session, the case is the same as with regular WPF application.

Otherwise you should ensure appropriate Session is active when object is created by a particular document/window to make it bound to that Session - AFAIK, that's the only case you should care about. Since all other objects are already bound to their Sessions, and Sessions are automatically activated when methods of these objects are invoked, there is no need to think about this e.g. in case when objects are created inside such calls.

And, if there is MDI, likely, you'll need to merge DisconnectedStates in some cases, as well as deal with version conflicts. See:

• DisconnectedState.Merge method.

• DisconnectedState.MergeMode (used in all lazy loading scenarios).

• Session.NotifyChanged method - it raises change notification via (INotifyXxx) on all cached objects having attached INotifyXxx event handlers.

Alex (Xtensive) wrote:

Session switching exception indicates that our Session activation aspect injected into some method of sessionBoundObjectO, that belongs to sessionX, tries to activate session of this object (i.e. sessionX), while sessionY (i.e. different Session) is already active.

Normally this means object that belongs to some different Session is, by some reason, used in the current Session - e.g. you pass EntitySet from sessionA to a method of entity from sessionB. So this is purely a check designed to prevent possible unintentional errors.

How to resolve it: obviously, all depends if this is really intentional, or not:

• This can be intentional, if you e.g. clone objects from some other database, or to/from a Session with attached DisconnectedState, i.e. you write something like this: clone.Property = source.Property. This is the case when you should use Session deactivation block (described below).

• Also, this can be an unintentional attempt to pass an object from different Session. In this case you should fix your own code - i.e. ensure the objects from appropriate Session is passed as an argument.

To detect, if the case you have is intentional or not, study the exception stack trace, or break on this exception and study local variables on the stack.

So what is session deactivation block?

using (Session.Deactivate()) {
  // Any Session can be activated here w/o exception, i.e. session switching check will pass inside this block
}

So e.g. code with property cloning must look like this in this case:

using (Session.Deactivate()) {
  clone.Property1 = source.Property1; // Note that clone.Property1 call will activate clone.Session inside it, as well as source.Property1 call will activate source.Session
  ...
  clone.PropertyN = source.PropertyN;
}

Note that:

• Currently there is no way to turn off this check at all, although I'm thinking about adding support for this. So if you'll see this is necessary, any proposals are welcome.

• It should be stressed everything will work even without this check. Earlier there were no such check at all - I decided to add it to help discovering such issues earlier. I.e. people tend to think this is some kind of DO-specific requirement, although it isn't. Normally it's wrong when you use objects from different Sessions, and moreover, make them using each other, so there is a default check for this. But I agree, if there is at least one case when this check must be disabled at all, there must be API for this.

Alex (Xtensive) wrote:

Forgot to add one important note: don't manually activate Session in UI thread, i.e. use Session.Open(domain, false) for to open it (or deactivate it there). Otherwise, you'll get Session switching exception when UI thread will try to e.g. read property of Entity from another Session.

This doesn't mean Session can't be activated when UI thread e.g. reads properties of your entities - on contrary, it will be activated in this case, but you must ensure no Session is already active at this moment. I.e. by default there should be no active Session in UI thread.

Alex Kofman wrote:

I recommend you to look at my sample of WPF application with DataObjects.Net DisconnectedState. You can find it here: http://alex-kofman.blogspot.com/2010/01 ... ample.html

There are several separated windows, each one uses its own disconnected session. In order to simplify usage of DisconnectedState I've introduced UiSession class that incapsulated UI-related operations with Session and DisconnectedState. Usually UiSession is used in following way:

private readonly UiSession uiSession = new UiSession();

public void EditCustomer(Key customerKey)
{
  uiSession.Open();
  using (uiSession.Activate())
  using (uiSession.Connect()) {
    DataContext = customerKey==null ? 
      new Customer() : 
      Query.Single<Customer>(customerKey);
  }
  Show();
}

private void ButtonOkClick(object sender, RoutedEventArgs e)
{
  try {
    uiSession.SaveChanges();
    Close();
  }
  catch(Exception exception) {
    MessageBox.Show(exception.Message, "Error", MessageBoxButton.OK, MessageBoxImage.Error);
  }
}

Although I'm not sure that this sample correctly works with DO 4.3, it was written for version 4.2...

Alex (Xtensive) wrote:

This sample is shipped as Sandbox project in v4.3, but AFAIK, it doesn't fully work now (i.e. I seen some exceptions while testing it few weeks ago).

I.e. the proposed approach there is correct in general (it's ~ like the one described here), but there are some minor issues.