具有DB2表锁定的事务性Web应用程序

Question

We have a Java web application where, at install time, a DBMS is chosen to store the application's data. We have about 8 choices with MS SQL Server, Oracle, MySQL and PostgreSQL being the most popular with our clients. We obviously interface with these databases using JDBC. The majority of the DB calls are just SQL within a transaction, very occasionally we'll use database sequences, or a stored procedure if sequences aren't available in the selected DB. The SQL used is very basic and runs on all supported databases without modification or DB specific syntax.

DB2 is an install option, but we seem to have problems with tables locking and pausing transactions, especially with concurrent users that are reading or writing from the same tables simultaneously. Maybe I should call these locks Deadlocks, because they will halt all the transactions where the same table is in use. By default we use a transaction isolation level of READ_COMMITTED, to enforce transaction integrity. Changing this to READ_UNCOMMITTED gets rid of the locks but it is obviously not a good way to run transactions.

All of our existing code "just works" with MySQL, PostgreSQL and Oracle. In SQL Server we enable SNAPSHOT ISOLATION on the database and don't have any problems deadlocks at the database level.

We are currently testing on DB2 9.1 and are seeing these deadlocks occurring. The DBMS has been installed with default options.

I have very little experience with DB2 and am not aware of any options that might remedy these locks, or if this is just how DB2 works.

Is there something simple that can make this work without having to synchonize code so that database tables are not accessed simultaneously. I also don't want to modify SQL to contain DB2 specific locking syntax. I won't rule out a problem with our code, but everything seems to work as expected on other DBMS.

Any ideas or recommendations?

Answer 1

DB2 locking mechanism works a bit differently than in other databases you are mentioning, which often exposes some lazy programming practices -- I mean no offence, it's just a fact of life. By the way, what you see are not deadlocks -- these are lock waits.

In DB2 locking issues are most commonly resolved by reducing the size of transactions (committing more frequently, processing fewer rows in each transaction) and proper indexing.

Beginning with DB2 9.7, you have an option of enabling the "currently committed" semantics , which makes DB2 behave more like these other databases in the sense that, instead of waiting for locks on updated rows to be released, queries access previously committed versions of those rows. This approach has its own negative effects though.