public inbox for [email protected]
help / color / mirror / Atom feedWould preparing internally during XAResource.end(xid, TMSUCCESS) works?
3+ messages / 2 participants
[nested] [flat]
* Would preparing internally during XAResource.end(xid, TMSUCCESS) works?
@ 2022-11-26 12:03 Andy Fan <[email protected]>
2022-12-01 16:01 ` Re: Would preparing internally during XAResource.end(xid, TMSUCCESS) works? Dave Cramer <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: Andy Fan @ 2022-11-26 12:03 UTC (permalink / raw)
To: [email protected]
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
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Would preparing internally during XAResource.end(xid, TMSUCCESS) works?
2022-11-26 12:03 Would preparing internally during XAResource.end(xid, TMSUCCESS) works? Andy Fan <[email protected]>
@ 2022-12-01 16:01 ` Dave Cramer <[email protected]>
2022-12-07 03:12 ` Re: Would preparing internally during XAResource.end(xid, TMSUCCESS) works? Andy Fan <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: Dave Cramer @ 2022-12-01 16:01 UTC (permalink / raw)
To: Andy Fan <[email protected]>; +Cc: [email protected]
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 <[email protected]> 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
>
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Would preparing internally during XAResource.end(xid, TMSUCCESS) works?
2022-11-26 12:03 Would preparing internally during XAResource.end(xid, TMSUCCESS) works? Andy Fan <[email protected]>
2022-12-01 16:01 ` Re: Would preparing internally during XAResource.end(xid, TMSUCCESS) works? Dave Cramer <[email protected]>
@ 2022-12-07 03:12 ` Andy Fan <[email protected]>
0 siblings, 0 replies; 3+ messages in thread
From: Andy Fan @ 2022-12-07 03:12 UTC (permalink / raw)
To: Dave Cramer <[email protected]>; +Cc: [email protected]
Hi Dave:
Thanks for your feedback and sorry for the late reply.
Hi Andy,
>
> Sorry I'm not much help here.
>
> Were you able to figure this out?
>
>
I've been working on this for a while. It would not work per
current PG server code. The biggest issue is when user
calls 'xa_end', he/she isn't intent to persist the 2pc
transaction, but the PG code would do that during the 'prepare
transaction' statement. In this case WE SHOULD NOT recover
it again during crash recovery. I'm hacking the pg server code
not do it until a user called 'xa_prepare'.
The internal way to do this is: during xa_end, I run the 'prepare
transaction xxx' statement and record a new xlog to rollback it
2pc, this is done at the end of the crash recovery stage. and
If the user runs the 'xa_prepare', I would add another xlog to
let the above thing not happen at the end of the crash recovery
stage.
(I hacked both JDBC driver and server code for the above stuff)
Besides this, I also find another issue that
connection 1:
xa_start('foo', ..);
insert into t select 1;
xa_end('foo', ..);
connection 2:
xa_start('foo', ..);
select * from t; ==> The above insert from connection 1 is visible for
current connection, but in our JDBC it doesn't.
I am also hacking this case as well, just record the transaction xid
which the 'foo' belongs to and add a new rule to the MVCC to let
the tuple be visible as well.
still tuned and testing now.
--
Best Regards
Andy Fan
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2022-12-07 03:12 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2022-11-26 12:03 Would preparing internally during XAResource.end(xid, TMSUCCESS) works? Andy Fan <[email protected]>
2022-12-01 16:01 ` Dave Cramer <[email protected]>
2022-12-07 03:12 ` Andy Fan <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox