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

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
>

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

Jose


Do you have optimistic or pessimistic locking set?

Roy Lambert [Team Elevate]

Roy

Optimistic

Eduardo

Jose

>Optimistic

Ah well, there goes that theory

Roy Lambert [Team Elevate]

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

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

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

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