This question is locked. New answers and comments are not allowed.
Hi there,
the WPF application i developed is based on a domain model approach data access layer.
It's multithreaded, and i have put a singleton to ensure only one access to the dbcontext simultaneously.
The backend configuration defines that:
The version i use is 2011.1.411.2.
Initially, i encountered some issues while accessing the context, because of several threads accessing it at the same time.
To workaround that, i have added some protection:
I'm not sure it's the correct way to work with multithreaded application, but it's the best i could do to avoid exceptions when saving the changes on the diagram if those protections were not put.
Today, is still have some problems, still when saving the changes on the context, even though i'm sure that no other access to the diagram are running.
2 exceptions occurs quite frequently.
First one is:
tx already active
‡ Telerik.OpenAccess.SPI.Backends.ThrowException(Exception e)
‡ Telerik.OpenAccess.RT.ExceptionWrapper.Throw()
‡ OpenAccessRuntime.DataObjects.OpenAccessPersistenceManagerImp.handleException(Exception x)
‡ OpenAccessRuntime.DataObjects.OpenAccessPersistenceManagerImp.beginCommon()
‡ OpenAccessRuntime.DataObjects.OpenAccessPersistenceManagerImp.begin()
‡ OpenAccessRuntime.DataObjects.OpenAccessPersistenceManagerImp.isResourceManagerEnlisted()
‡ OpenAccessRuntime.DataObjects.OpenAccessPersistenceManagerImp.isActive()
‡ OpenAccessRuntime.DataObjects.OpenAccessPersistenceManagerImp.commit()
‡ Telerik.OpenAccess.RT.EnlistableObjectScope.CommitChanges()
Second one is:
Telerik.OpenAccess.OpenAccessContextBase.SaveChanges(ConcurrencyConflictsProcessingMode failureMode)
‡ Telerik.OpenAccess.OpenAccessContextBase.SaveChanges()
‡ PHS.BusinessObjects.dbContext.SaveChangesInDiagram() dans BusinessObjects\dbContext.cs:ligne 177
Telerik.OpenAccess.RT.sql.SQLException: L'opération de transaction ne peut pas être exécutée parce que des demandes sont en attente dans cette transaction. (in english: the transaction operation cannot be performed because there are pending requests working on this transaction.)
‡ Telerik.OpenAccess.RT.Adonet2Generic.Impl.ConnectionImp.commit()
‡ OpenAccessRuntime.Relational.conn.LoggingConnection.commit()
‡ OpenAccessRuntime.Relational.conn.PooledConnection.commit()
It seems that there is a sort of delay when committing a transaction, or something like that, and the next transaction cannot access the db because of that, isn't it?
As a second workaround (you will see how bad it is), i have put a try catch block around the save changes, and if it fails, i wait 1 seconds and try again, and this seems to work at each time...
Can anyone give a hand on that, as i'm not far from despair...
Any advice on how to work properly with multithreaded applications, or any tutorial or example would also help (i have not found much information in the integrated help on multithreading concerns).
And more important, merry christmas and happy new year to everybody,
Antoine.
the WPF application i developed is based on a domain model approach data access layer.
It's multithreaded, and i have put a singleton to ensure only one access to the dbcontext simultaneously.
The backend configuration defines that:
- Isolation level is serialization
- Transaction mode is pessimistic locking first
- Multithreaded context option is checked
The version i use is 2011.1.411.2.
Initially, i encountered some issues while accessing the context, because of several threads accessing it at the same time.
To workaround that, i have added some protection:
- a lock on the diagram each time a read or a write is done on it
- a semaphore on the update of any object of the context (set prior to update attributes and released after the SaveChanges)
I'm not sure it's the correct way to work with multithreaded application, but it's the best i could do to avoid exceptions when saving the changes on the diagram if those protections were not put.
Today, is still have some problems, still when saving the changes on the context, even though i'm sure that no other access to the diagram are running.
2 exceptions occurs quite frequently.
First one is:
tx already active
‡ Telerik.OpenAccess.SPI.Backends.ThrowException(Exception e)
‡ Telerik.OpenAccess.RT.ExceptionWrapper.Throw()
‡ OpenAccessRuntime.DataObjects.OpenAccessPersistenceManagerImp.handleException(Exception x)
‡ OpenAccessRuntime.DataObjects.OpenAccessPersistenceManagerImp.beginCommon()
‡ OpenAccessRuntime.DataObjects.OpenAccessPersistenceManagerImp.begin()
‡ OpenAccessRuntime.DataObjects.OpenAccessPersistenceManagerImp.isResourceManagerEnlisted()
‡ OpenAccessRuntime.DataObjects.OpenAccessPersistenceManagerImp.isActive()
‡ OpenAccessRuntime.DataObjects.OpenAccessPersistenceManagerImp.commit()
‡ Telerik.OpenAccess.RT.EnlistableObjectScope.CommitChanges()
Second one is:
Telerik.OpenAccess.OpenAccessContextBase.SaveChanges(ConcurrencyConflictsProcessingMode failureMode)
‡ Telerik.OpenAccess.OpenAccessContextBase.SaveChanges()
‡ PHS.BusinessObjects.dbContext.SaveChangesInDiagram() dans BusinessObjects\dbContext.cs:ligne 177
Telerik.OpenAccess.RT.sql.SQLException: L'opération de transaction ne peut pas être exécutée parce que des demandes sont en attente dans cette transaction. (in english: the transaction operation cannot be performed because there are pending requests working on this transaction.)
‡ Telerik.OpenAccess.RT.Adonet2Generic.Impl.ConnectionImp.commit()
‡ OpenAccessRuntime.Relational.conn.LoggingConnection.commit()
‡ OpenAccessRuntime.Relational.conn.PooledConnection.commit()
It seems that there is a sort of delay when committing a transaction, or something like that, and the next transaction cannot access the db because of that, isn't it?
As a second workaround (you will see how bad it is), i have put a try catch block around the save changes, and if it fails, i wait 1 seconds and try again, and this seems to work at each time...
Can anyone give a hand on that, as i'm not far from despair...
Any advice on how to work properly with multithreaded applications, or any tutorial or example would also help (i have not found much information in the integrated help on multithreading concerns).
And more important, merry christmas and happy new year to everybody,
Antoine.
3 Answers, 1 is accepted
0
Hi Antoine,
The pattern that we encourage our customers to use, as a best practices approach, is to handle the OpenAccess in a per-thread fashion. This means that there should be one instance of an OpenAccessContext for each thread performing CRUD operations in your application. Otherwise there is always a chance to have multiple threads accessing data that is not intended to be shared among threads.
I would like to suggest you to have a look into the following KB articles, one of those targets Web scenarios and the second one, a normal multi-threaded desktop scenario.
I would like to tell you that the OpenAccessContext is a light-weight object and it will present no overhead to your application if you hold multiple instances of it. This would probably mean some major re-factoring for you but this is really the approach I would suggest you at the moment.
Please do let us know if this approach is acceptable for you and if you have any concerns regarding it.
Greetings,
Zoran
the Telerik team
The pattern that we encourage our customers to use, as a best practices approach, is to handle the OpenAccess in a per-thread fashion. This means that there should be one instance of an OpenAccessContext for each thread performing CRUD operations in your application. Otherwise there is always a chance to have multiple threads accessing data that is not intended to be shared among threads.
I would like to suggest you to have a look into the following KB articles, one of those targets Web scenarios and the second one, a normal multi-threaded desktop scenario.
I would like to tell you that the OpenAccessContext is a light-weight object and it will present no overhead to your application if you hold multiple instances of it. This would probably mean some major re-factoring for you but this is really the approach I would suggest you at the moment.
Please do let us know if this approach is acceptable for you and if you have any concerns regarding it.
Greetings,
Zoran
the Telerik team
Q3’11 of Telerik OpenAccess ORM is available for download. Register for the What's New in Data Tools webinar to see what's new and get a chance to WIN A FREE LICENSE!
0
Saene
Top achievements
Rank 1
Rank 1
answered on 28 Dec 2011, 04:12 PM
Thanks Zoran for your quick answer.
I will do as recommended for the next applications i will develop.
In the mean time, do you have any idea on what happens when saving my diagram, and why the exceptions detailled occur? Is there a delay when saving the changes on the diagram, which would explain such behavior?
Thanks anyway,
Antoine.
I will do as recommended for the next applications i will develop.
In the mean time, do you have any idea on what happens when saving my diagram, and why the exceptions detailled occur? Is there a delay when saving the changes on the diagram, which would explain such behavior?
Thanks anyway,
Antoine.
0
Hi Sean,
Zoran
the Telerik team
What happens is that indeed two threads are accessing the underlying objects that are used by the OpenAccess API. Even if you do use semaphores, there are operations that can be delayed because of database server resources, connection initialization etc. and that is the reason that you are seeing such problems. I believe that re-factoring your current solution to use the scope-per-thread approach is the most secure solution that will guarantee you will not get similar problems in the future when this project gets deployed.
Kind regards,Zoran
the Telerik team
Q3’11 of Telerik OpenAccess ORM is available for download. Register for the What's New in Data Tools webinar to see what's new and get a chance to WIN A FREE LICENSE!