public inbox for [email protected]help / color / mirror / Atom feed
Would 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]> 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-12-01 16:01 Dave Cramer <[email protected]> parent: 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-12-07 03:12 Andy Fan <[email protected]> parent: Dave Cramer <[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