Re: Handling transaction failure due to concurrency errors
От | jwhiting@redhat.com |
---|---|
Тема | Re: Handling transaction failure due to concurrency errors |
Дата | |
Msg-id | 1520506772.4589.10.camel@redhat.com обсуждение исходный текст |
Ответ на | Re: Handling transaction failure due to concurrency errors (Christopher BROWN <brown@reflexe.fr>) |
Ответы |
Re: Handling transaction failure due to concurrency errors
|
Список | pgsql-jdbc |
Hi Christopher, On a side note you should look at the Byteman project. Byteman makes fault injection for testing purposes very easy. http://byteman.jboss.org/ In your case using Byteman gets round the effort involved to precisely re-create a failure scenario. Testing when your re-try logic kicks in (or not). Jeremy On Fri, 2018-03-02 at 16:27 +0100, Christopher BROWN wrote: > Tom, > > That's what I was looking for, so thanks, I'll give it a go. > > Best regards, > Christopher > > > > On 2 March 2018 at 16:21, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Christopher BROWN <brown@reflexe.fr> writes: > > > Thanks for the quick reply. OK for the explanation, and I don't > > mind > > > implementing the retry logic for this case... I just don't know > > how to > > > detect when my code encounters this case (as opposed to other > > cases that > > > can arise, such as unresolved foreign keys when importing data; I > > don't > > > want to get into an infinite retry loop because it will never > > work in these > > > other cases). > > > > Yes, you should only retry in this way for the specific case of a > > serialization failure (SQLSTATE 40001). > > > > regards, tom lane > >
В списке pgsql-jdbc по дате отправления: