Eduardo,

<< 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. >>

Not correct.  Transactions do *not* block reads, only other commits or
writes.

<< 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) >>

Again, it's not that simple.  You're looking only at the write side, when
the actual scenario involves, read locks, write locks, transaction locks
(intent to write locks), and row locks, all of which can interact in
different ways.  For example, having a transaction in effect does not block
another user from reading and acquiring a lock on a row not involved in the
transaction.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

> << 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.

I understand why. But I think does not cost to ask.

Eduardo

Tim

>
> Not correct.  Transactions do *not* block reads, only other commits or
> writes.
>
Ok. I know that but it was missed by my afirmation.

> Again, it's not that simple.  You're looking only at the write side, when
> the actual scenario involves, read locks, write locks, transaction locks
> (intent to write locks), and row locks, all of which can interact in
> different ways.
I imagine it is not simple.

> For example, having a transaction in effect does not block another user
> from reading and acquiring a lock on a row not involved in the
> transaction.
Ok. I agree, but one transaction need to wait for another transaction ends
with commit or rollback. Again, I know this is not easy, I put this thread
to know another opinions about this situation.

Let´s wait for Enterprise version.

Eduardo

Eduardo

> 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.

I understand that for your business model you require an atomic transaction.

What I was trying to establish is whether theses processes that takes 10
seconds (a long time for a transaction would be faster in total if
executed in parallel without the tranaction locking overhead.  If say 3 or 4
of these processes run at the same time (without a transaction) only take
marginally longer than the 10 seconds to process then it is worth
investigating how to do a psuedo transaction to fulfill the business need.
If the time taken is roughly 3 or 4 times the original 10 seconds then the
actual way the process works needs to be investigated.

John

John

> What I was trying to establish is whether theses processes that takes 10
> seconds (a long time for a transaction would be faster in total if
> executed in parallel without the tranaction locking overhead.  If say 3 or
> 4
> of these processes run at the same time (without a transaction) only take
> marginally longer than the 10 seconds to process then it is worth
> investigating how to do a psuedo transaction to fulfill the business need.
> If the time taken is roughly 3 or 4 times the original 10 seconds then the
> actual way the process works needs to be investigated.

No problem. I will try to investigate again the business logic and see if I
can reduce the transaction time.

BTW, thanks to everyone in this thread.

Eduardo

Eduardo

I missed in you original reply that there are 15 branches.  If you are using
connections with a high latency (eg internet) this could cause the
transaction to be very slow.  If this is the case I would suggest the
database processing should take place at the centre through maybe a stored
procedure.

Cheers

John

John

> I missed in you original reply that there are 15 branches.  If you are
> using
> connections with a high latency (eg internet) this could cause the
> transaction to be very slow.  If this is the case I would suggest the
> database processing should take place at the centre through maybe a stored
> procedure.

The database processing has already done at server side. BTW, the
connections to the server are made using Terminal Service technology.

Eduardo

Tim Young [Elevate Software] wrote:
> 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,
   I was under the impression EDB 1.x did row locking. Or am I
mistaken?  So aren't transactions just locking rows?

Dave

Dave

As I know the locking mechanism deal with the entire database or table
(restrictive transaction) exactly like DBISAM do.

Eduardo

Dave,

<< I was under the impression EDB 1.x did row locking. Or am I mistaken?  So
aren't transactions just locking rows? >>

The locking in EDB is detailed here:

http://www.elevatesoft.com/manual?action=mantopic&id=edb1sql&category=0&topic=11

and here:

http://www.elevatesoft.com/manual?action=mantopic&id=edb1sql&category=0&topic=12

--
Tim Young
Elevate Software
www.elevatesoft.com