Re: Handling transaction failure due to concurrency errors - Mailing list pgsql-jdbc

From jwhiting@redhat.com
Subject Re: Handling transaction failure due to concurrency errors
Date
Msg-id 1520506772.4589.10.camel@redhat.com
Whole thread Raw
In response to Re: Handling transaction failure due to concurrency errors  (Christopher BROWN <brown@reflexe.fr>)
Responses Re: Handling transaction failure due to concurrency errors  (Christopher BROWN <brown@reflexe.fr>)
List 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 by date:

Previous
From: Bear Giles
Date:
Subject: Re: TimeZone issue with 42.2.1
Next
From: Christopher BROWN
Date:
Subject: Re: Handling transaction failure due to concurrency errors