Concurrency control vs table locking

Posts   
 
    
yj
User
Posts: 39
Joined: 07-Aug-2007
# Posted on: 10-Aug-2007 11:19:55   

Hi again, another beginner type of questions, hope you guys can enlighten me. I had read thru the strategy for LLBL's Save() function dealing with concurrency control. During a concurrency access, with a predicate specified, it can actually look into the table to check on whether it (Save function) is updating from the orginal data. However, my team mates feel that such method creates a lot of overhead if there are a lot of attributes to be compared. Hence they suggest that using a locking of table method to solve this problem. So my problem is, how do we lock a table manually using the generated code from LLBLGen Pro? Thank you very much.

arschr
User
Posts: 894
Joined: 14-Dec-2003
# Posted on: 10-Aug-2007 14:16:20   

You don't say what database you are using?

In Sql server, at least, there is a timestamp datatype. It allows this kind of concurancy control without checking each field in your entity against the database.

I would love to see an example where a table lock was "better" than any row based concurrency check.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39910
Joined: 17-Aug-2003
# Posted on: 11-Aug-2007 17:41:26   

Indeed, what Al says. Table locks are pretty bad in performance. Also, we let the database do the locking. That's 1) much more efficient (start a transaction and the locking is done for you) and 2) it avoids dangling locks of processes which are keeping locks forever because the user went home and let the application run.

Check the documentation section Using the generated code -> Adapter/selfservicing -> Using entity classes -> Concurrency control simple_smile

Frans Bouma | Lead developer LLBLGen Pro