|
評価：
 三日月夜空（CV：井上麻里奈）,三日月夜空,井上麻里奈,柏崎星奈（CV：伊藤かな恵）,柏崎星奈,伊藤かな恵 メディアファクトリー ￥ 890 (2011-11-25) |
やー、ファルセットが効果的に使われているなぁ。進行などはオーソドックスだけど、ところどころのキメとか展開がおもしろい。井上さん、あまり堅苦しくないけどキッチリ歌っている。よかよか。
C/Wは。。。。。チト私はダメだな。。。。。。
JUGEMテーマ：音楽
]]>
|
|
評価：
三日月夜空（CV：井上麻里奈）,三日月夜空,井上麻里奈,柏崎星奈（CV：伊藤かな恵）,柏崎星奈,伊藤かな恵 メディアファクトリー ￥ 890 (2011-11-25) |
|
評価：
奥野 幹也 技術評論社 ￥ 3,465 (2010-06-12) |
|
評価：
--- 日経BP社 ￥ 1,490 (2011-12-08) |
|
|
|
評価：
coaltar of the deepers,Ringo Deathstarr,堀江由衣,SECRET SHINE キングレコード ￥ 1,159 (2011-08-31) |
|
評価：
友達つくり隊,三日月夜空（CV：井上麻里奈）,柏崎星奈（CV：伊藤かな恵）,楠幸村（CV：山本希望）,志熊理科（CV：福圓美里）,羽瀬川小鳩（CV：花澤香菜）,高山マリア（CV：井口裕香）,井上麻里,奈伊藤かな恵 メディアファクトリー ￥ 860 (2011-10-26) |
|
評価：
--- バッファロー ￥ 5,144 (2010-12-01) |
これに対してMySQLでのJDBCドライバ実装のConnector/Jの現在メンテナンスされているバージョンは 次の一覧のように少ないため、まよわずConnector/J 5.1.xを使ってください。
DD MON YEAR 5.0.x 5.1.x ------------------------------------------ 22 DEC 2005 5.0.0 ----- 11 JUL 2006 5.0.1 ----- 11 JUL 2006 5.0.2 ----- 26 JUL 2006 5.0.3Be ----- 20 OCT 2006 5.0.4 ----- 02 MAR 2007 5.0.5 ----- 11 APR 2007 ----- 5.1.0 Al 15 MAY 2007 5.0.6 22 JUN 2007 ----- 5.1.1 Al 29 JUN 2007 ----- 5.1.2 Be 20 JUL 2007 5.0.7 10 SEP 2007 ----- 5.1.3 RC 09 OCT 2007 5.0.8 5.1.5 GA 07 MAR 2008 ----- 5.1.6 GA 21 OCT 2008 ----- 5.1.7 GA 16 JUL 2009 ----- 5.1.8 GA 21 SEP 2009 ----- 5.1.9 GA 23 SEP 2009 ----- 5.1.10 GA 21 JAN 2010 ----- 5.1.11 GA 18 FEB 2010 ----- 5.1.12 GA 24 JUN 2010 ----- 5.1.13 GA 06 DEC 2010 ----- 5.1.14 GA 10 FEB 2011 ----- 5.1.15 GA 16 MAY 2011 ----- 5.1.16 GA 07 JUL 2011 ----- 5.1.17 GA 04 OCT 2011 ----- 5.1.18 GA
上記以外には3.0, 3.1がありますが最終リリースは次のようになっており、更新されていません。
またConnector/J 5.0 は、上記のとおり現状の最終リリースD.6.2.1. Changes in MySQL Connector/J 5.0.8 (09 October 2007)であり、2008年以降は5.1しか更新されていません。
Connector/J 5.1はJava 1.5以降で動作し、MySQL 4.1以降への接続に対応しています。各Connector/Jバージョンの内容と対応するJava/MySQLのバージョンについては次のマニュアルをご参照ください。
またConnector/JもConnector/Net同様にMySQLクライアントライブラリ(libmysql)は利用していないため、クライアントライブラリは不要(かつクライアントライブラリのバージョンに左右されない)です。
Connector/Jのマニュアルは以下のリンクでpdfにまとめられているので、これをダウンロードして参照すると便利ですよ。ではでは。
Connector/Jのマニュアル(英文) 他のフォーマット(html, epub)やConnector/J以外のドキュメントはこちらからチェック!
| INNODB_LOCK_WAITS |独自: ロック待ち情報 | INNODB_LOCKS |独自: ロック競合情報 | INNODB_TRX |独自: トランザクション情報通常一つの接続ではトランザクションのBEGIN; COMMIT;を何度か行います。つまり一つの接続はシリアルに複数のトランザクションを実行(そしてそれぞれに違うトランザクションid)、コマンド実行時はCOMMANDにQuery表示で、その実行時間がTIMEに出力され、コマンド実行が終わるとCOMMANDにSleep表示で、Sleepになってからの時間が表示されるということです。
mysql> show processlist; +----+------+-----------------+------+---------+------+----------+----------------------------------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+------+-----------------+------+---------+------+----------+----------------------------------------------+ | 5 | root | localhost:52752 | test | Sleep | 335 | | NULL | | 8 | root | localhost:62954 | test | Sleep | 100 | | NULL | | 9 | root | localhost:62956 | test | Query | 41 | Updating | update table1 set v2 = 'kimura' where i1 = 1 | | 11 | root | localhost:63349 | test | Query | 28 | Updating | update table1 set v2 = 'kimura' where i1 = 1 | : |117 | root | localhost:52831 | NULL | Query | 0 | NULL | show processlist | +----+------+-----------------+------+---------+------+----------+----------------------------------------------+ まず9,11の接続のトランザクションIDが何かを確認してみましょう。 mysql> select trx_mysql_thread_id as Id, trx_id from information_schema.innodb_trx where trx_mysql_thread_id in (9,11); +----+--------+ | Id | trx_id | +----+--------+ | 11 | 60017 | | 9 | 60016 | +----+--------+ 2 rows in set (0.00 sec) トランザクションIDが分かるとinnodb_lock_waitsテーブルで、どのトランザクションIDに待たされているのか、がわかります。 mysql> select * from information_schema.innodb_lock_waits where requesting_trx_id in (60016,60017); +-------------------+-------------------+-----------------+------------------+ | requesting_trx_id | requested_lock_id | blocking_trx_id | blocking_lock_id | +-------------------+-------------------+-----------------+------------------+ | 60017 | 60017:38:3:6 | 60016 | 60016:38:3:6 | | 60017 | 60017:38:3:6 | 60015 | 60015:38:3:6 | | 60016 | 60016:38:3:6 | 60015 | 60015:38:3:6 | +-------------------+-------------------+-----------------+------------------+60017は60016,60015を待っていて、60016は60015を待っている、ということは60015が今回のロックの保持者のようです。再度innodb_trxで確認してみましょう。これを確認すると接続id(trx_mysql_thread_id)は8ということが分かります。
mysql> select * from information_schema.innodb_trx where trx_id = 60015¥G
*************************** 1. row ***************************
trx_id: 60015
trx_state: RUNNING
trx_started: 2011-10-16 14:06:27
trx_requested_lock_id: NULL
trx_wait_started: NULL
trx_weight: 3
trx_mysql_thread_id: 8
trx_query: NULL
trx_operation_state: NULL
trx_tables_in_use: 0
trx_tables_locked: 0
trx_lock_structs: 2
trx_lock_memory_bytes: 376
trx_rows_locked: 1
trx_rows_modified: 1
trx_concurrency_tickets: 0
trx_isolation_level: REPEATABLE READ
trx_unique_checks: 1
trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
trx_adaptive_hash_latched: 0
trx_adaptive_hash_timeout: 10000
1 row in set (0.00 sec)
運用上とりあえず当該ロック待ちを解消するには次のように接続id 8をkillすれば事足ります。
mysql> kill 8;
しかしながら、根本的な問題の解決には接続id 8が発行したどのクエリがロックを取得していて、それは問題ないか、また接続id 8はなぜトランザクションをホールドしたままだったのか、を調べる必要があります。残念ながら問題が起こってから、過去にさかのぼって接続id 8が発行したクエリを調べる方法はありません。そのため、再現環境をつくりだし、一般クエリログやMEMのQUANなどで発行クエリを確認しながら、問題再現するか、
当該アプリケーションのクエリシーケンスを確認し、どのシーケンスが問題なのか、などを調べる必要があります。具体的にどのようなロックがかかっていたのかは、innodb_lockテーブルの内容を参考にしてください。 (これらの情報スキーマのテーブルを組み合わせてわかりやすく表示する例がSH2さんのブログエントリにあります)
なお、ロック待ちを再現できる場合は、テストや今回のような原因究明の場合、InnoDBのロック待ちの長さを長くすると検出しやすくなります。MySQL 5.5からセッション単位で設定できるようになったので、以下のように設定すればロック待ちを長くして、その間にいろいろと調べることができます。(このように長くするのは開発時やQA時のみにしてください)
mysql> set innodb_lock_wait_timeout = 28800; -- 8時間に設定 ]]>
|
評価：
--- 日経BP社 ￥ 1,490 (2011-10-08) |