Deadlocks und Integration-Module

Author: khounlivong
Publication Date: 4/24/2013 5:46

Wir benutzen das u.a. DynamicDatabaseAccess-Module (FSIntegration) und haben intensiven Zugriff durch unsere Redakteure. In der nahen Vergangenheit hatten wir sowohl Probleme mit der Datenbank-Connectivität als auch mit der Thread-Anzahl des Systemes. Der Datenbank-Server liegt zentral und bedient content-mäßig sowohl das CMS als auch unsere Frontend.

Hinweisen folgend haben wir sowohl die Threadzahl erhöht (conf/fs-webapp.xml) als auch die MySQL-Parameter entsprechend Doku angepaßt:

jdbc.POOLCYCLE=60

jdbc.POOLMAX=1

jdbc.POOLMIN=1

jdbc.POOLTIMEOUT=180

Jetzt erhalten wir Deadlock-Exceptions in den Clients beim Speichern und Löschen (.doStore, .doDelete), zu den eingestellten Save/NotSaved-Seiten kommt das System in dem Fall gar nicht. Die Vorgaben für die DB sind default:

mysql> show variables like "%inno%";
+-----------------------------------------+------------------------+
| Variable_name                           | Value                  |
+-----------------------------------------+------------------------+
| have_innodb                             | YES                    |
| ignore_builtin_innodb                   | OFF                    |
| innodb_adaptive_hash_index              | ON                     |
| innodb_additional_mem_pool_size         | 1048576                |
| innodb_autoextend_increment             | 8                      |
| innodb_autoinc_lock_mode                | 1                      |
| innodb_buffer_pool_size                 | 8388608                |
| innodb_checksums                        | ON                     |
| innodb_commit_concurrency               | 0                      |
| innodb_concurrency_tickets              | 500                    |
| innodb_data_file_path                   | ibdata1:10M:autoextend |
| innodb_data_home_dir                    |                        |
| innodb_doublewrite                      | ON                     |
| innodb_fast_shutdown                    | 1                      |
| innodb_file_io_threads                  | 4                      |
| innodb_file_per_table                   | OFF                    |
| innodb_flush_log_at_trx_commit          | 1                      |
| innodb_flush_method                     |                        |
| innodb_force_recovery                   | 0                      |
| innodb_lock_wait_timeout                | 50                     |
| innodb_locks_unsafe_for_binlog          | OFF                    |
| innodb_log_buffer_size                  | 1048576                |
| innodb_log_file_size                    | 5242880                |
| innodb_log_files_in_group               | 2                      |
| innodb_log_group_home_dir               | ./                     |
| innodb_max_dirty_pages_pct              | 90                     |
| innodb_max_purge_lag                    | 0                      |
| innodb_mirrored_log_groups              | 1                      |
| innodb_open_files                       | 300                    |
| innodb_rollback_on_timeout              | OFF                    |
| innodb_stats_method                     | nulls_equal            |
| innodb_stats_on_metadata                | ON                     |
| innodb_support_xa                       | ON                     |
| innodb_sync_spin_loops                  | 20                     |
| innodb_table_locks                      | ON                     |
| innodb_thread_concurrency               | 8                      |
| innodb_thread_sleep_delay               | 10000                  |
| innodb_use_legacy_cardinality_algorithm | ON                     |
+-----------------------------------------+------------------------+
38 rows in set (0.00 sec)

Irgendeine Idee, wie man das Debuggen kann?

Die fs-server.log enthält als einzigen Hinweis innerhalb der Exception:

java.sql.SQLException: Deadlock found when trying to get lock; try restarting transaction