Login ProductsSalesSupportDownloadsAbout |
Home ŧ Technical Support ŧ ElevateDB Technical Support ŧ Support Forums ŧ ElevateDB General ŧ View Thread |
Messages 1 to 10 of 20 total |
High concurrency |
Mon, May 5 2008 8:56 PM | Permanent Link |
Jose Eduardo Helminsky | Enterprise version is still in project but high concurrency could be addressed in EDB 2.X or even in EDB 3.X but before Enterprise version ?
Of course it will only work in C/S environment because the locks should be handled by the server side. I am asking this because I have a specific customer with 120 users and at least 30 of them access the same tables to perform a task. This task takes almost 10 seconds to finish, but with 30 users, it could take 29 x 10 seconds to finish and now I donīt know a way to solve this. The application is already using restricted transaction but this is not the problem. Split the tables in 30 tables and perform a "Insert into" from these 30 tables into the main table at night could be a solution but it will involves a lot of adjusts. Someone have something related with this ? Could you share your experience ? Thanks anyway for any comments Eduardo |
Mon, May 5 2008 11:03 PM | Permanent Link |
Steve Forbes Team Elevate | Hi Eduardo,
One way of resolving this situation is to edit using a detached approach. Read the record being edited into a structure and immediately disconnect from the DB (or create a new record directly into the structure without any DB access). Keep a delta image of the record contents. When editing is finished lock the DB, reread the target record and check whether there have been any third party changes (only if editing) if none begin a transaction and save the record. Your DB should then only be locked for a couple of seconds max at a time. You will of course need to handle the case where the record one user is editing has already been edited and saved by another user in the meantime (i.e. the delta is out of date) HTH -- Best Regards Steve [Team Elevate] "Jose Eduardo Helminsky" <contato@hpro.com.br> wrote in message news:6005ACF7-F5F3-4CA3-969E-B5932300A50C@news.elevatesoft.com... > Enterprise version is still in project but high concurrency could be > addressed in EDB 2.X or even in EDB 3.X but before Enterprise version ? > > Of course it will only work in C/S environment because the locks should be > handled by the server side. > > I am asking this because I have a specific customer with 120 users and at > least 30 of them access the same tables to perform a task. This task > takes almost 10 seconds to finish, but with 30 users, it could take 29 x > 10 seconds to finish and now I donīt know a way to solve this. The > application is already using restricted transaction but this is not the > problem. Split the tables in 30 tables and perform a "Insert into" from > these > 30 tables into the main table at night could be a solution but it will > involves a lot of adjusts. > > Someone have something related with this ? Could you share your experience > ? > > Thanks anyway for any comments > > Eduardo > |
Tue, May 6 2008 6:39 AM | Permanent Link |
"Jose Eduardo Helminsky" | Steve
In my case, I donīt know if it will help because the time consuming is exactly for edit/save records, I think it could reduce from 10 to something lower but I donīt know if it pays the work. I will try to implement some changes and tell you what happen. BTW, thanks for your comments Eduardo |
Tue, May 6 2008 8:39 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Jose
Do you have optimistic or pessimistic locking set? Roy Lambert [Team Elevate] |
Tue, May 6 2008 9:24 AM | Permanent Link |
"Jose Eduardo Helminsky" | Roy
Optimistic Eduardo |
Tue, May 6 2008 1:53 PM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Jose
>Optimistic Ah well, there goes that theory Roy Lambert [Team Elevate] |
Wed, May 7 2008 6:39 AM | Permanent Link |
"Jose Eduardo Helminsky" | Roy
I am pretty sure the code is correct. But the problem is the way that DBISAM and ElevateDB locks the database or tables. Tim knows about this. This is not a problem but a design issue. It will be completelly solved with Enterprise version (I hope so). This occurs because DBISAM/ElevateDB lock the entire table blocking other users. If for example we could select the range of records to be blocked the problem will disapear but I know too that is a completelly redesign of the current approach. Eduardo |
Wed, May 7 2008 7:41 AM | Permanent Link |
"John Hay" | Eduardo
If you do not use a transaction how long does the task take for 1,2,3... users at the same time? In other words is is the serialization of the tasks caused by the transaction or just the tasks themselves thatr causes the slowdown? Cheers John |
Wed, May 7 2008 9:15 AM | Permanent Link |
"Jose Eduardo Helminsky" | John
I donīt know how long does it take but it *MUST* be under transaction because it involves processing stock operations, financial operations, and another specific operations that can not be broken. The process of starting a transaction is instantaneous but the tasks causes this slowdown. How I said before, the process does not take so long (less than 10 seconds) but the number of users performing the same task is the problem. This is a company with 15 branches (I donīt know if it is the correct word). Every time someone starts an operation that takes some seconds it blocks other users even if they are just reading other records far from those are inside the operation. Database lock = Common DBISAM/ElevateDB behavior Table lock = Restritected transaction in both DBISAM/ElevateDB Record lock = desired model (Tim already know that and this feature will be in Enterprise version of ElevateDB) Eduardo |
Wed, May 7 2008 12:54 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Eduardo,
<< Enterprise version is still in project but high concurrency could be addressed in EDB 2.X or even in EDB 3.X but before Enterprise version ? >> No. -- Tim Young Elevate Software www.elevatesoft.com |
Page 1 of 2 | Next Page ŧ | |
Jump to Page: 1 2 |
This web page was last updated on Tuesday, September 17, 2024 at 04:19 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |