contention from TClientDataset.CloneCursor?

[zenpicker]

I'm using CloneCursor extensively in a multithreaded app so that multiple sessions/users can independently access a shared copy of a client dataset with about 70,000 rows. It looks from the documentation as if I should be able to do this with no conflict or collision between the users, since each has their own view of the dataset. This is true - everyone correctly gets their own record pointer, filters, ranges, etc. with no problem,

However, something is causing the app to lock up at low concurrency levels - just a few users. One possible suspect is CloneCursor. **Is there any undocumented overhead in having multiple users cursored into the same in-memory client dataset?** Are there contention or locking issues in the VCL that would cause an app failure? Hope not - it's central to my design!

 

[bledazemi]

I have never used TClientDataSet however i have experienced the type of application locking via some other TDataSet type components.

In my case the locking occurred at the database engine server. I was using MySQL database engine. Briefly my problem was due to the fact that one of my clients did a pending "Select" statement which placed a "Read lock" on the table and did not let go until the Select was finished, in my case the "Select" statement would never finish. Later in the code the same client tried to edit a record which basically meant it had to wait for the "Read lock" to go which never went. So my application would hanged infinitelly.

In my case the problem was solved by changing "FetchAll" property of my client dataset components to true. Now i dont know if TClientDataSet has such a "FetchAll" property or whether any of this applies to your situation. I just felt i'd tell my experience in hope that it may help you a little.

Good luck

What database engine do you have at the back-end ?