Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 11 to 20 of 20 total |
High concurrency |
Wed, May 7 2008 12:57 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Wed, May 7 2008 2:12 PM | Permanent Link |
"Jose Eduardo Helminsky" | 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 |
Wed, May 7 2008 2:20 PM | Permanent Link |
"Jose Eduardo Helminsky" | 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 |
Mon, May 12 2008 5:17 AM | Permanent Link |
"John Hay" | 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 |
Mon, May 12 2008 6:10 AM | Permanent Link |
"Jose Eduardo Helminsky" | 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 |
Mon, May 12 2008 6:38 AM | Permanent Link |
"John Hay" | 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 |
Mon, May 12 2008 12:26 PM | Permanent Link |
"Jose Eduardo Helminsky" | 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 |
Fri, May 30 2008 12:56 AM | Permanent Link |
Dave Harrison | 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 |
Fri, May 30 2008 6:21 AM | Permanent Link |
"Eduardo \(HPro\)" | Dave
As I know the locking mechanism deal with the entire database or table (restrictive transaction) exactly like DBISAM do. Eduardo |
Fri, May 30 2008 12:22 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
« Previous Page | Page 2 of 2 | |
Jump to Page: 1 2 |
This web page was last updated on Thursday, May 23, 2024 at 07:54 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |