Re: Handling transaction failure due to concurrency errors
От | Christopher BROWN |
---|---|
Тема | Re: Handling transaction failure due to concurrency errors |
Дата | |
Msg-id | CAHL_zcNiKoNKjqE9mPPUd1JXTV7dTQ--B2Uxt3Z37TWcjuBOGQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Handling transaction failure due to concurrency errors (jwhiting@redhat.com) |
Список | pgsql-jdbc |
Hi Jeremy,
Thanks for the suggestion, trying out Byteman was already on my TODO list for other cases, and it could be handy here too.
Thanks,
Christopher
On 8 March 2018 at 11:59, <jwhiting@redhat.com> wrote:
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 по дате отправления: