BuyLog In
Ticket T135880
Visible to All Users

SQLConnection does not suppor parallel transactions

created 11 years ago

Hello, we have a simple scenario (attached). One page with just a Button "Save", if two users make click at the same time on the button will throw an Exception: SQLConnection does not suppor parallel transactions (we use UnitOfWork with ExplicitBeginTransaction, ExplicitCommitTransaction and ExplicitRollbackTransaction)

Is there any way to throw this Exception only if the object is the same? Because too many users can access to this page with different objects and when two users click on "Save", the application throws this error.

Thank you,

Sign in to comment on this post

Answers approved by DevExpress Support

created 11 years ago

Hello Daniel.

It is unclear why you are using explicit transactions, but the way you are using them is incorrect. As it is mentioned in Using Explicit Transactions article, a session or unit of work that starts an explicit transaction must be the exclusive owner of the database connection. Therefore, only one explicit transaction can be open at a time. In your application, all users connected to your web site share the same database connection held by the static data layer created in XpoHelper.

Do you really need explict transactions? The standard Unit Of Work is usually enough for most tasks.

    Show previous comments (3)
    DevExpress Support Team 11 years ago

      I suppose you are doing all these calls in a single web request. If so, you can do the following without explicit transactions:

      C#
      using (UnitOfWork session = XpoHelper.GetNewUnitOfWork()) {  
    try {  
        var father = new Father(session);  
        var son1 = new Son(session);  
        father.Children.Add(son1);  
        var son2 = new Son(session);  
        father.Children.Add(son2);  
        var son3 = new Son(session);  
        father.Children.Add(son3);  
        session.CommitChanges();  
    } catch (Exception ex) {  
        //inform about the error  
    }  
}

      The result is either all objects will be successfully saved or nothing changed in the database. XPO automatically puts all operations into a transaction.
      There is no need to deal with the (database-generated) key value manually if you link objects by storing references instead of foreign key values or implement associations.

      DM DM
      Daniel Mamone 11 years ago

        Ok Michael, thanks, we understand your example… but
        Two questions:

        1. Can I get the ID of the Father before adding their childrens?
        2. In the above example (our scenario), when I create multiple connections … What is the best way to close those connections?
          Thank you.
        DevExpress Support Team 11 years ago
          1. Without using explicit transactions, you can't get the real ID before all changes are committed, but it is not usually needed, as I demonstrated. When working with an ORM framework, it is better to operate on references rather than exact key values.
          2. To close the connction created by a data layer, dispose of the session and the data layer when you finished using them.
          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.