下に起因するPostgreSQLの更新の同時実行のデッドロック

まず、デッドロックの背景

レシート一括印刷は、デッドロックによって引き起こされる非同期同時印刷トリガーの使用、トリガー同時実行で、その結果、（すべての50ミリ秒後にトリガを超える9000データ）を印刷中には、インターフェイスが更新されたとき、印刷回数は、PostgreSQLが発生した場合

次のように与えられた固有：

図1は、 ###エラーが発生しながらパラメータ設定
 2の更新組t_sc_receipt print_num =合体（print_num、0）+ 1、print_ts = ### SQLを？
3  ###原因：org.postgresql.util.PSQLException：ERROR：デッドロックが検出された
 4    详细を：ためのプロセス19540の待機ShareLockトランザクション12520113オン; プロセス19539によってブロック。
5つのプロセス19539のを待つためのトランザクション12520112にShareLock。プロセス19540によってブロック。
6    建议：サーバーのログを参照してくださいするために、クエリの詳細。
7    在位置：しばらく「t_sc_receipt」関係で更新されたタプル（329,3）を再チェック
 8  。SQL []; ERROR：デッドロックが検出
 9    详细：プロセス19540のを待つためのトランザクション12520113にShareLock。プロセス19539によってブロック。
10のプロセス19539のを待つためのトランザクション12520112にShareLock。プロセス19540によってブロック。
11    建议：サーバーのログを参照してくださいするために、クエリの詳細。
12    在位置：ながら、関係"t_sc_receipt"に更新されたタプル（329,3）を再チェックします。ERROR：デッドロックが検出されたネストされた例外はorg.postgresql.util.PSQLExceptionが
 13    详细：プロセス19540のを待つためトランザクション12520113上ShareLock。プロセス19539によってブロック。
14のプロセス19539のを待つためのトランザクション12520112にShareLock。プロセス19540によってブロック。
15    建议：サーバーのログを参照してくださいするために、クエリの詳細。
16    在位置：ながら "t_sc_receipt"関係で更新されたタプル（329,3）を再検査
 17      org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.doTranslate（SQLErrorCodeSQLExceptionTranslator.java:263で）
 18      org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslatorで。翻訳（AbstractFallbackSQLExceptionTranslator.java:73 ）
 19     org.mybatis.spring.MyBatisExceptionTranslator.translateExceptionIfPossible（MyBatisExceptionTranslator.java:73で）
 20      org.mybatis.spring.SqlSessionTemplate $ SqlSessionInterceptor.invoke（SqlSessionTemplate.java:368で）
 21      com.sun.proxyで。$ Proxy57.update（不明なソース）
 22      org.mybatis.spring.SqlSessionTemplate.update（SqlSessionTemplate.java:254で）
 23      com.xxx.framework.mybatis.dao.impl.MyBatisDaoImpl.updateBySql（MyBatisDaoImpl.java:531で）
 24      com.xxxで.dscsettle.receipt.ReceiptService。updatePrintNum（ReceiptService.java:160 ）
 25     com.xxx.dscsettle.receipt.ReceiptService $$ FastClassBySpringCGLIB $$ 82e91731.invokeで（<発生> ）
 26      org.springframework.cglib.proxy.MethodProxy.invoke（MethodProxy.java:204で）
 27      org.springframework.aopで.framework.CglibAopProxy $ DynamicAdvisedInterceptor.intercept（CglibAopProxy.java:651 ）
 28      com.xxx.dscsettle.receipt.ReceiptService $$ $$ EnhancerBySpringCGLIB 67b6a353.updatePrintNumで（<生成> ）
 29      com.alibaba.dubbo.common.bytecodeで.Wrapper72.invokeMethod（Wrapper72.java）
 30      com.alibaba.dubbo.rpc.proxy.javassist.JavassistProxyFactory $ 1.doInvoke（JavassistProxyFactory.java:46で）
 31     com.alibaba.dubbo.rpc.proxy.AbstractProxyInvoker.invoke（AbstractProxyInvoker.java:72で）
 32      com.alibaba.dubbo.rpc.protocol.InvokerWrapper.invoke（InvokerWrapper.java:53で）
 33      com.onlyou.frameworkで.log.DubboLogServiceFilter.invoke（DubboLogServiceFilter.java:28 ）
 34      $ 1.invoke（ProtocolFilterWrapper.java:69 com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapperで）
 35      com.alibaba.dubbo.rpc.filter.ExceptionFilterで。 invoke（ExceptionFilter.java:64 ）
 36      com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapperで$ 1.invoke（ProtocolFilterWrapper.java:69 ）
 37     com.alibaba.dubbo.rpc.filter.TimeoutFilter.invoke（TimeoutFilter.java:42で）
 38      $ 1.invoke（ProtocolFilterWrapper.java:69 com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapperで）
 39      com.alibabaで。 dubbo.monitor.support.MonitorFilter.invoke（MonitorFilter.java:75 ）
 40      $ 1.invoke（ProtocolFilterWrapper.java:69 com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapperで）
 41      com.alibaba.dubbo.rpc.protocolで.dubbo.filter.TraceFilter.invoke（TraceFilter.java:78 ）
 42      com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapperで$ 1.invoke（ProtocolFilterWrapper.java:69 ）
 43     com.alibaba.dubbo.rpc.filter.ContextFilter.invoke（ContextFilter.java:61で）
 44      $ 1.invoke（ProtocolFilterWrapper.java:69 com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapperで）
 45      com.alibabaで。 dubbo.rpc.filter.GenericFilter.invoke（GenericFilter.java:132 ）
 46      $ 1.invoke（ProtocolFilterWrapper.java:69 com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapperで）
 47      com.alibaba.dubbo.rpc.filterで.ClassLoaderFilter.invoke（ClassLoaderFilter.java:38 ）
 48      com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapperで$ 1.invoke（ProtocolFilterWrapper.java:69 ）
 49     com.alibaba.dubbo.rpc.filter.EchoFilter.invoke（EchoFilter.java:38で）
 50      $ 1.invoke（ProtocolFilterWrapper.java:69 com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapperで）
 51      com.alibabaで。 dubbo.rpc.protocol.dubbo.DubboProtocol $ 1.reply（DubboProtocol.java:98 ）
 52      com.alibaba.dubbo.remoting.exchange.support.header.HeaderExchangeHandler.handleRequestで（HeaderExchangeHandler.java:98 ）
 53      com.alibabaで.dubbo.remoting.exchange.support.header.HeaderExchangeHandler.received（HeaderExchangeHandler.java:170 ）
 54      com.alibaba.dubbo.remoting.transport.DecodeHandler.receivedで（DecodeHandler.java:52 ）
 55     com.alibaba.dubbo.remoting.transport.dispatcher.ChannelEventRunnable.run（ChannelEventRunnable.java:81で）
 56      java.util.concurrent.ThreadPoolExecutor.runWorker（ThreadPoolExecutor.java:1145で）
 57      java.util.concurrent.ThreadPoolExecutorで$ Worker.run（ThreadPoolExecutor.java:615 ）
 58      java.lang.Thread.run（Thread.java:745で）
 59  org.postgresql.util.PSQLException：起因するエラー：デッドロックが検出された
 60    详细：プロセス19540のを待つためトランザクション12520113上ShareLock。プロセス19539によってブロック。
61のプロセス19539のを待つためトランザクション12520112上ShareLock。プロセス19540によってブロック。
62    建议：サーバーのログを参照してくださいするために、クエリの詳細。

二、原因分析

（私たちは、先端からデッドロックがデータベースのPostgreSQLで発生与えられている知っている：検出デッドロックエラーが   絶えず更新にページング、デッドロックが発生した検出）、およびそれが起こったときに通常のロジックの下で、回を印刷するの同時更新に配置することができますレシート印刷時間が間違って行くべきではありません、ここで印刷バッチ更新の数に誤りがありました。

1.デッドロックに起因する競合リソース更新データは、データベースの行ロックをもたらすはずである場合に生じます

2.ので一括編集を使用すると、すべての変更を完了していない場合ので、インデックスは手放すことはないだろう、デフォルトのトランザクションで、このように同時アクセス数のデッドロックを生じさせます、

3.研究が問題の原因で、重複した行ロックの原因として最も可能性が高いことが判明した、私は最終的に理由があるため、コードのロジックである見つけ、それぞれその結果、空と判断されたではない一括更新idList、およびSQL私たちは、データのテーブル全体更新する必要が異なる取引によるものは、直接、デッドロックが生じ、資源、互いないのを待ちます。

 

第三に、解決の問題と拡大

バッチ更新は、デッドロックには2つのソリューションがあります

ループのための単一の変更に一括更新が、サーバー上の圧力を増加させるこの方法1。

2.データの更新の最初のスクリーニングを行い、重複データが出て削除

自身がupadateの反復を繰り返されていないため、この問題は、問題を解決するためにちょうどいいidLIst入ってくるコードを解くの中。

質問：postgresqlのデッドロックの下で同時更新はshareLockそれを発生しますか？

繰り返し通常の状況下でのアップデートでながら、デッドロックをもたらすべきではないトランザクション比較的デッドロックされている更新プログラムが発生する可能性があります。

同時に、また、我々は、ブロガーはPostgreSQLのデッドロックはいくつかのバージョンが表示され、解決するために、次の2つのパラメータを設定することで解決することができる可能性が同時更新のバグであってもよい見ました：

autovacuum_vacuum_scale_factor = 0.03
autovacuum_analyze_scale_factor = 0.03

 

参考地址：http://blog.chinaunix.net/uid-20726500-id-4773950.html
https://blog.51cto.com/372550/2387517