MIME-Version: 1.0
References: 
 <CAKU4AWqF=FgsnyjSorBKLeCi50iB7NmT4KaQWKmp-gCgKmd_uQ@mail.gmail.com>
In-Reply-To: 
 <CAKU4AWqF=FgsnyjSorBKLeCi50iB7NmT4KaQWKmp-gCgKmd_uQ@mail.gmail.com>
From: Dave Cramer <davecramer@gmail.com>
Date: Thu, 1 Dec 2022 11:01:43 -0500
Message-ID: 
 <CADK3HH+F6AxVp-Z0qtiK8sc1vC7ekuprria_kzTcUg0yBfGzrA@mail.gmail.com>
Subject: Re: Would preparing internally during XAResource.end(xid,
 TMSUCCESS) works?
To: Andy Fan <zhihui.fan1213@gmail.com>
Cc: pgsql-jdbc@lists.postgresql.org
Content-Type: multipart/alternative; boundary="00000000000053068205eec657d3"
Archived-At: 
 <https://www.postgresql.org/message-id/CADK3HH%2BF6AxVp-Z0qtiK8sc1vC7ekuprria_kzTcUg0yBfGzrA%40mail.gmail.com>
Precedence: bulk

--00000000000053068205eec657d3
Content-Type: text/plain; charset="UTF-8"

Hi Andy,

Sorry I'm not much help here.

Were you able to figure this out?

Dave Cramer


On Sat, 26 Nov 2022 at 07:03, Andy Fan <zhihui.fan1213@gmail.com> wrote:

> Hi:
>
> One of our customers is coming from Oracle and they use XAResource like
> this.
>
> xaResource1.start(xid, ..);
> xaResource1.getConnection.doSomeDML();
> xaResource1.end(xid, TMSUCCESS);
>
> xaResource2.prepare(xid);
>
> This works in Oracle but doesn't work in PostgreSQL's JDBC, since we have
> to use the same XAResource instance to prepare the xid.
>
> I know why we have to 'prepare transaction xxx' in the same connection for
> PostgreSQL kernel. For now my question is:  can we do the 'prepare
> transaction 'xxx'' during XAResource.end(xid, TMSUCCESS); and later in
> XAResource2.prepare(xid), we can double check if it is prepared already,
> if so we can just return XA_OK. the benefit of this is that the user
> doesn't
> have to prepare in the same connection.
>
> Asking customers not to do this is not an option in my case,
> and I'm not asking our community to do so, I'm just asking what
> would be wrong if we do so.
>
> Any feedback is welcome,  Thanks!
>
>
> --
> Best Regards
> Andy Fan
>

--00000000000053068205eec657d3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi=C2=A0Andy,<div><br></div><div>Sorry I&=
#39;m not much help here.</div><div><br></div><div>Were you able to figure =
this out?</div><div><br clear=3D"all"><div><div dir=3D"ltr" class=3D"gmail_=
signature" data-smartmail=3D"gmail_signature">Dave Cramer</div></div><br></=
div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_at=
tr">On Sat, 26 Nov 2022 at 07:03, Andy Fan &lt;<a href=3D"mailto:zhihui.fan=
1213@gmail.com">zhihui.fan1213@gmail.com</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Hi:<br><br>On=
e of our customers is coming from Oracle and they use XAResource like<br>th=
is.<br><br>xaResource1.start(xid, ..);<br>xaResource1.getConnection.doSomeD=
ML();<br>xaResource1.end(xid, TMSUCCESS);<br><br>xaResource2.prepare(xid);<=
br><br>This works in Oracle but doesn&#39;t work in PostgreSQL&#39;s JDBC, =
since we have<br>to use the same XAResource instance to prepare the xid.<br=
><br>I know why we have to &#39;prepare transaction xxx&#39; in the same co=
nnection for<br>PostgreSQL kernel. For now my question is: =C2=A0can we do =
the &#39;prepare<br>transaction &#39;xxx&#39;&#39; during XAResource.end(xi=
d, TMSUCCESS); and later in<br>XAResource2.prepare(xid), we can double chec=
k if it is prepared already,<br>if so we can just return XA_OK. the benefit=
 of this is that the user doesn&#39;t</div><div>have to prepare in the same=
 connection.<br><br>Asking=C2=A0customers not to do this is not an option i=
n my case,=C2=A0</div><div>and I&#39;m not asking our community to do so, I=
&#39;m just asking what</div><div>would be wrong if we do so.</div><div><br=
>Any feedback is welcome,=C2=A0 Thanks!<br></div><br clear=3D"all"><div><br=
></div>-- <br><div dir=3D"ltr"><div dir=3D"ltr">Best Regards<div>Andy Fan</=
div></div></div></div>
</blockquote></div></div>

--00000000000053068205eec657d3--