BuyLog In
Ticket Q433576
Visible to All Users

Unexpected SessionMixingException

created 13 years ago

i encountered an issue when trying to bind controls to properties of a xpobject's child property.
the error occurs when the main xpobject is loaded and then a child property is changed.

xpo throws a sessionmixingexception when trying to assign a new value to the child property although they actually belong to the same session.

example:

there is an "Order" with a property "ResponsiblePerson" (typeof(Employee)). the order's view should habe some labels which display important data about this person. now i change the responsible person:

DoMagicStuff()
{
int key = SelectResponsiblePerson(); // ListBox, Form, whatever…
order.ResponsilbePerson = order.Session.GetObjectByKey<Employee>(key); // throws exception
}

the error does not occur when there are no controls bound to properties of CurrentOrder.ResponsilbePerson.

i attached a sample project to illustrate the problem.

Sign in to comment on this post

Answers

created 13 years ago (modified 13 years ago)

Hi Fred,
This issue is caused by the fact that when you replace a UnitOfWork with a new one, recreate objects and change the XPCollection.Session property, UI controls are still bound to original property descriptors. Since XPO persistent objects use XPPropertyDescriptors that contain a reference to a Session, you got a mix of an older and new sessions.
Note that the XPBaseCollection.Session Property documentation suggests against modifying this property programmatically. If you need to get fresh data, either re-create collections and re-bind controls when after creating a new session, or call the Session.DropIdentityMap method of the existing session and reload objects and collections.

    Comments (2)
    FC FC
    Fred Colschen 13 years ago

      Hello Micheal,
      Thanks for your quick response.
      >> If you need to get fresh data, either re-create collections and re-bind controls when creating a new session
      Re-creating bindings for every control in a view after reloading/creating a new object is not an option. In my opinion this contradicts the general idea of DataBinding.
      >> call the Session.DropIdentityMap method of the existing session and reload objects and collections.
      Thanks for the advice, though i was not able to make my example work. Would you please take a look at my example (in the first post) and tell me were to put Session.DropIdentityMap()? The SessionMixingException still occurs regardless of where i put the call.
      Is there a best practice to bind controls to a xp-object and properties of its sub-properties? Works like a charm with Non-XPObjects and default BindingSources. This causes me quite a headache.

      DevExpress Support Team 13 years ago

        Hi Fred,
        Thank you for your feedback. We have implemented persistent objects and collections to mimic the data binding behavior of ADO.NET DataSets. If you need a different behavior, inherit your persistent classes from PersistentBase and use IList instead of XPCollection.
        I have modified your project to use a single unit of work and refresh it via the DropIdentityMap method. It is attached.

        Sign in to comment on this post
        created 13 years ago (modified 13 years ago)

        i also tried to create a bindingsource, set its datasource-property to the xpcollection and its datamember property to the child property and then bind the controls to the binding source… but due to ICustomTypeDescriptor BindingSources became a bunch of hooey :)

          Sign in to comment on this post

          Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.

          Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.