Re: pgsql XA with weblogic 8.1?

Hello,

Any of you have experience yet using Heikki's newfangled XA implementation
with weblogic 8.1? I'm getting the exception below.

ERROR: Could not establish connection with database core
Nested exception: <<null>>
Unexpected exception while enlisting XAConnection java.sql.SQLException: XA
error: XAER_RMERR : A resource manager error has occured in the transaction
branch start() failed on resource 'dfc.core': XAER_RMERR : A resource manager
error has occured in the transaction branch
org.postgresql.xa.PGXAException: suspend/resume and join not implemented
at org.postgresql.xa.PGXAConnection.start(PGXAConnection.java:103)
at weblogic.jdbc.jta.DataSource.start(DataSource.java:629)
at
weblogic.transaction.internal.XAServerResourceInfo.start(XAServerResourceInfo.java:1140)
at
weblogic.transaction.internal.XAServerResourceInfo.xaStart(XAServerResourceInfo.java:1072)
at
weblogic.transaction.internal.XAServerResourceInfo.enlist(XAServerResourceInfo.java:255)
at
weblogic.transaction.internal.ServerTransactionImpl.enlistResource(ServerTransactionImpl.java:463)
at weblogic.jdbc.jta.DataSource.enlist(DataSource.java:1392)
at
weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1334)
at weblogic.jdbc.jta.DataSource.getConnection(DataSource.java:396)
at weblogic.jdbc.jta.DataSource.connect(DataSource.java:354)
at
weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:305)

--
--------------------------------------------------------------
Jan de Visser                     jdevisser(at)digitalfairway(dot)com

                Baruk Khazad! Khazad ai-menu!
--------------------------------------------------------------

On Mon, 28 Nov 2005, Jan de Visser wrote:

> Any of you have experience yet using Heikki's newfangled XA implementation
> with weblogic 8.1? I'm getting the exception below.
>
> ERROR: Could not establish connection with database core
> Nested exception: <<null>>
> Unexpected exception while enlisting XAConnection java.sql.SQLException: XA
> error: XAER_RMERR : A resource manager error has occured in the transaction
> branch start() failed on resource 'dfc.core': XAER_RMERR : A resource manager
> error has occured in the transaction branch
> org.postgresql.xa.PGXAException: suspend/resume and join not implemented
> at org.postgresql.xa.PGXAConnection.start(PGXAConnection.java:103)

I don't use weblogic, but you might try addding either or both of these
parameters:

http://e-docs.bea.com/wls/docs90/wlsmbeanref/core/index.html
JDBCXAParamsBean.XaEndOnlyOnce
JDBCXAParamsBean.KeepXaConnTillTxComplete

Kris Jurka

On Monday 28 November 2005 12:39, Kris Jurka wrote:
> On Mon, 28 Nov 2005, Jan de Visser wrote:
> > Any of you have experience yet using Heikki's newfangled XA
> > implementation with weblogic 8.1? I'm getting the exception below.
> >
> > ERROR: Could not establish connection with database core
> > Nested exception: <<null>>
> > Unexpected exception while enlisting XAConnection java.sql.SQLException:
> > XA error: XAER_RMERR : A resource manager error has occured in the
> > transaction branch start() failed on resource 'dfc.core': XAER_RMERR : A
> > resource manager error has occured in the transaction branch
> > org.postgresql.xa.PGXAException: suspend/resume and join not implemented
> > at org.postgresql.xa.PGXAConnection.start(PGXAConnection.java:103)
>
> I don't use weblogic, but you might try addding either or both of these
> parameters:
>
> http://e-docs.bea.com/wls/docs90/wlsmbeanref/core/index.html
> JDBCXAParamsBean.XaEndOnlyOnce
> JDBCXAParamsBean.KeepXaConnTillTxComplete

Thanks, but that didn't work.

It seems that wl calls a start( xid, TMRESUME ) (or TMJOIN, but I guess
TMRESUME would make more sense) even though it never called end( xid,
TMSUSPEND ) before (this is from browsing the driver code).

Would it make sense to silently ignore a TMRESUME if the same xid is still
active? I can cook up a patch...

>
> Kris Jurka

JdV!!

--
--------------------------------------------------------------
Jan de Visser                     jdevisser(at)digitalfairway(dot)com

                Baruk Khazad! Khazad ai-menu!
--------------------------------------------------------------

On Monday 28 November 2005 14:19, Jan de Visser wrote:
> On Monday 28 November 2005 12:39, Kris Jurka wrote:
> > On Mon, 28 Nov 2005, Jan de Visser wrote:
> > > Any of you have experience yet using Heikki's newfangled XA
> > > implementation with weblogic 8.1? I'm getting the exception below.
> > >
> > > ERROR: Could not establish connection with database core
> > > Nested exception: <<null>>
> > > Unexpected exception while enlisting XAConnection
> > > java.sql.SQLException: XA error: XAER_RMERR : A resource manager error
> > > has occured in the transaction branch start() failed on resource
> > > 'dfc.core': XAER_RMERR : A resource manager error has occured in the
> > > transaction branch
> > > org.postgresql.xa.PGXAException: suspend/resume and join not
> > > implemented at
> > > org.postgresql.xa.PGXAConnection.start(PGXAConnection.java:103)
> >
> > I don't use weblogic, but you might try addding either or both of these
> > parameters:
> >
> > http://e-docs.bea.com/wls/docs90/wlsmbeanref/core/index.html
> > JDBCXAParamsBean.XaEndOnlyOnce
> > JDBCXAParamsBean.KeepXaConnTillTxComplete
>
> Thanks, but that didn't work.
>
> It seems that wl calls a start( xid, TMRESUME ) (or TMJOIN, but I guess
> TMRESUME would make more sense) even though it never called end( xid,
> TMSUSPEND ) before (this is from browsing the driver code).
>
> Would it make sense to silently ignore a TMRESUME if the same xid is still
> active? I can cook up a patch...

Well, that wasn't it. I debugged a bit, and it turns out that WL sends a
start(xid,TMJOIN) when committing entity EJBs. Don't ask me why (I'm not an
XA expert by any stretch of the imagination). What I did is took the
pragmatic approach, and allow a TMJOIN if the connection is in STATE_ENDED
and if the xid is the same as the current xid. This seems to work.

Would that be acceptable/make sense?

JdV!!

--
--------------------------------------------------------------
Jan de Visser                     jdevisser(at)digitalfairway(dot)com

                Baruk Khazad! Khazad ai-menu!
--------------------------------------------------------------

On Mon, 28 Nov 2005, Jan de Visser wrote:

> Well, that wasn't it. I debugged a bit, and it turns out that WL sends a
> start(xid,TMJOIN) when committing entity EJBs. Don't ask me why (I'm not an
> XA expert by any stretch of the imagination). What I did is took the
> pragmatic approach, and allow a TMJOIN if the connection is in STATE_ENDED
> and if the xid is the same as the current xid. This seems to work.
>

What's the order of calls made?

start(xid, TMNOFLAGS)
end(xid, TMSUCCESS)
start(xid, TMJOIN)
prepare(xid)
commit(xid, false)

or does the start call only happen once, with TMJOIN instead of TMNOFLAGS.
It's tough to get an idea of what calls are actually being made and on
which connections. Any chance you could send us a log trace using
Oliver's new logging code in 8.2dev with loglevel=2?

Kris Jurka

On Tuesday 29 November 2005 00:50, Kris Jurka wrote:
> On Mon, 28 Nov 2005, Jan de Visser wrote:
> > Well, that wasn't it. I debugged a bit, and it turns out that WL sends a
> > start(xid,TMJOIN) when committing entity EJBs. Don't ask me why (I'm not
> > an XA expert by any stretch of the imagination). What I did is took the
> > pragmatic approach, and allow a TMJOIN if the connection is in
> > STATE_ENDED and if the xid is the same as the current xid. This seems to
> > work.
>
> What's the order of calls made?
>
> start(xid, TMNOFLAGS)
> end(xid, TMSUCCESS)
> start(xid, TMJOIN)
> prepare(xid)
> commit(xid, false)

I believe that this is the case.

>
> or does the start call only happen once, with TMJOIN instead of TMNOFLAGS.
> It's tough to get an idea of what calls are actually being made and on
> which connections. Any chance you could send us a log trace using
> Oliver's new logging code in 8.2dev with loglevel=2?

Will attempt to do this later this week. Am out of the office today and
tomorrow.

>
> Kris Jurka

--
--------------------------------------------------------------
Jan de Visser                     jdevisser(at)digitalfairway(dot)com

                Baruk Khazad! Khazad ai-menu!
--------------------------------------------------------------

On Tuesday 29 November 2005 00:50, Kris Jurka wrote:
> Any chance you could send us a log trace using
> Oliver's new logging code in 8.2dev with loglevel=2?

Anybody care to explain how I set that up using a DataSource? There does not
seem to be a setLogLevel on BaseDataSource, and I can't use a URL either...

Thanks,

JdV!!

--
--------------------------------------------------------------
Jan de Visser                     jdevisser(at)digitalfairway(dot)com

                Baruk Khazad! Khazad ai-menu!
--------------------------------------------------------------

On Tue, 6 Dec 2005, Jan de Visser wrote:

> On Tuesday 29 November 2005 00:50, Kris Jurka wrote:
>> Any chance you could send us a log trace using
>> Oliver's new logging code in 8.2dev with loglevel=2?
>
> Anybody care to explain how I set that up using a DataSource? There does not
> seem to be a setLogLevel on BaseDataSource, and I can't use a URL either...

Doesn't seem to be directly possible. The loglevel variables are static
however, so you should be able to just call
org.postgresql.Driver.setLogLevel, unless there's some classloader issues.

If that doesn't work, can you try a quick & dirty patch to enable logging,
and recompile from source? I can do that if you don't have the build
environment ready.

- Heikki

Heikki Linnakangas wrote:
> On Tue, 6 Dec 2005, Jan de Visser wrote:
>
>> On Tuesday 29 November 2005 00:50, Kris Jurka wrote:
>>
>>> Any chance you could send us a log trace using
>>> Oliver's new logging code in 8.2dev with loglevel=2?
>>
>>
>> Anybody care to explain how I set that up using a DataSource? There
>> does not
>> seem to be a setLogLevel on BaseDataSource, and I can't use a URL
>> either...

Unfortunately the DataSource stuff has been a bit neglected when it
comes to connection parameters, there's lots of stuff you can't set there :(

> Doesn't seem to be directly possible. The loglevel variables are static
> however, so you should be able to just call
> org.postgresql.Driver.setLogLevel, unless there's some classloader issues.

They're now actually per-connection, but if you set a level at the
Driver level that becomes the default for new connections.

Or you can create a properties file called
"org/postgresql/driverconfig.properties" and put it in the driver's
classpath, and the driver will load defaults for all properties from there.

-O

Well, it seems that the list doesn't like attachments. So here again with my
log in-line...

On Tuesday 29 November 2005 00:50, Kris Jurka wrote:
> On Mon, 28 Nov 2005, Jan de Visser wrote:
> > Well, that wasn't it. I debugged a bit, and it turns out that WL sends a
> > start(xid,TMJOIN) when committing entity EJBs. Don't ask me why (I'm not
> > an XA expert by any stretch of the imagination). What I did is took the
> > pragmatic approach, and allow a TMJOIN if the connection is in
> > STATE_ENDED and if the xid is the same as the current xid. This seems to
> > work.
>
> What's the order of calls made?
>
> start(xid, TMNOFLAGS)
> end(xid, TMSUCCESS)
> start(xid, TMJOIN)
> prepare(xid)
> commit(xid, false)
>
> or does the start call only happen once, with TMJOIN instead of TMNOFLAGS.
> It's tough to get an idea of what calls are actually being made and on
> which connections. Any chance you could send us a log trace using
> Oliver's new logging code in 8.2dev with loglevel=2?
>
> Kris Jurka

I hacked BaseDataSource to allow for a LogLevel attribute, and PGXAConnection
to print the flags passed to start, and got the attached.

So it seems to be the case that the tx is started with TMNOFLAGS, ended, and
restarted with TMJOIN in the ejbStore phase (The 'Creating' message is
actually in ejbCreate()), which confirms my theory.

So my question again: Would it be OK to allow TMJOIN on an ended but
non-committed tx with the same Xid? Like so:

// Check implementation deficiency preconditions
if (flags == TMRESUME)
throw new PGXAException(GT.tr("suspend/resume and join not implemented"),
XAException.XAER_RMERR);
if ( ( flags == TMJOIN ) && ( ( state != STATE_ENDED ) ||
!xid.equals( currentXid ) ) ) {
throw new PGXAException(GT.tr("Transaction interleaving not implemented"),
XAException.XAER_RMERR);
}
if ( ( state == STATE_ENDED ) && ( !xid.equals( currentXid ) ||
( flags != TMJOIN ) ) ) {
throw new PGXAException(GT.tr("Transaction interleaving not implemented"),
XAException.XAER_RMERR);
}

As I mentioned before, this works for me.

JdV!!

Log:

08:47:41.442 (1) XAResource 1d12d43: starting transaction xid =
BEA1-000426CF2CA2CC69504A-6466632E636F7265 with flags TMNOFLAGS
08:47:41.444 (1) simple execute,
handler=org(dot)postgresql(dot)jdbc2(dot)AbstractJdbc2Statement$StatementResultHandler(at)17b285e,
maxRows=0, fetchSize=0, flags=1
08:47:41.445 (1) FE=> Bind(stmt=S_1,portal=null)
08:47:41.445 (1) FE=> Execute(portal=null,limit=0)
08:47:41.445 (1) FE=> Parse(stmt=null,query="SELECT id FROM
tableSerializedXML WHERE enttype=$1 AND id=$2",oids={1043,1043})
08:47:41.445 (1) FE=> Bind(stmt=null,portal=null,$1=<controlpaneldef>,
$2=<eoss-controlpanel>)
08:47:41.446 (1) FE=> Describe(portal=null)
08:47:41.446 (1) FE=> Execute(portal=null,limit=0)
08:47:41.446 (1) FE=> Sync
08:47:41.447 (1) <=BE BindComplete [null]
08:47:41.447 (1) <=BE CommandStatus(BEGIN)
08:47:41.447 (1) <=BE ParseComplete [null]
08:47:41.447 (1) <=BE BindComplete [null]
08:47:41.447 (1) <=BE RowDescription(1)
08:47:41.447 (1) <=BE CommandStatus(SELECT)
08:47:41.448 (1) <=BE ReadyForQuery(T)
[07 084741.449]:LOW:9597-ExecuteThrea:XMLEntity_9v:Type controlpaneldef, ID
eos
Creating
08:47:41.455 (1) XAResource 1d12d43: ending transaction xid =
BEA1-000426CF2CA2CC69504A-6466632E636F7265
[07 084741.457]:DET:9597-ExecuteThrea:XMLEntity_9v:Type controlpaneldef, ID
eos
ejbStore Type controlpaneldef, ID eoss-controlpanel
[07 084741.458]:LOW:9597-ExecuteThrea:XMLEntity_9v:Type controlpaneldef, ID
eos
Storing
08:47:41.586 (1) XAResource 1d12d43: starting transaction xid =
BEA1-000426CF2CA2CC69504A-6466632E636F7265 with flags TMJOIN
08:47:41.589 (1) simple execute,
handler=org(dot)postgresql(dot)jdbc2(dot)AbstractJdbc2Connection$TransactionCommandHandler(at)40bc88,
maxRows=0, fetchSize=0, flags=22
08:47:41.590 (1) FE=> Parse(stmt=S_3,query="ROLLBACK",oids={})
08:47:41.590 (1) FE=> Bind(stmt=S_3,portal=null)
08:47:41.590 (1) FE=> Execute(portal=null,limit=1)
08:47:41.591 (1) FE=> Sync
08:47:41.591 (1) <=BE ParseComplete [S_3]
08:47:41.592 (1) <=BE BindComplete [null]
08:47:41.592 (1) <=BE CommandStatus(ROLLBACK)
08:47:41.592 (1) <=BE ReadyForQuery(I)
SQLException: SQLState() vendor code(-3)
java.sql.SQLException: XA error: XAER_RMERR : A resource manager error has
occured in the transaction branch start() failed on resource 'dfc.core':
XAER_RMERR : A resource manager error has occured in the transaction branch
org.postgresql.xa.PGXAException: suspend/resume and join not implemented
at org.postgresql.xa.PGXAConnection.start(PGXAConnection.java:118)
at
weblogic.jdbc.wrapper.VendorXAResource.start(VendorXAResource.java:50)
at weblogic.jdbc.jta.DataSource.start(DataSource.java:629)
at
weblogic.transaction.internal.XAServerResourceInfo.start(XAServerResourceInfo.java:1140)
at
weblogic.transaction.internal.XAServerResourceInfo.xaStart(XAServerResourceInfo.java:1072)
at
weblogic.transaction.internal.XAServerResourceInfo.enlist(XAServerResourceInfo.java:255)
at
weblogic.transaction.internal.ServerTransactionImpl.enlistResource(ServerTransactionImpl.java:463)
at weblogic.jdbc.jta.DataSource.enlist(DataSource.java:1392)
at
weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1334)
at weblogic.jdbc.jta.DataSource.getConnection(DataSource.java:396)
at weblogic.jdbc.jta.DataSource.connect(DataSource.java:354)
at
weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:305)
at
dfc.util.database.J2EEConnectionFactory.createConnection(J2EEConnectionFactory.java:57)

--
--------------------------------------------------------------
Jan de Visser                     jdevisser(at)digitalfairway(dot)com

                Baruk Khazad! Khazad ai-menu!
--------------------------------------------------------------

On Wed, 7 Dec 2005, Jan de Visser wrote:

> So my question again: Would it be OK to allow TMJOIN on an ended but
> non-committed tx with the same Xid? Like so:

Looks OK to me. Looking at the XA spec, the end + start(TMJOIN)
sequence is valid, so we should support if we can.

- Heikki

On Wednesday 07 December 2005 12:53, Heikki Linnakangas wrote:
> On Wed, 7 Dec 2005, Jan de Visser wrote:
> > So my question again: Would it be OK to allow TMJOIN on an ended but
> > non-committed tx with the same Xid? Like so:
>
> Looks OK to me. Looking at the XA spec, the end + start(TMJOIN)
> sequence is valid, so we should support if we can.

Great. So shall I clean up my patch (error messages etc) and send it here? Or
how does that work? I'd also like to submit my changes to BaseDataSource
allowing for loglevel to be set...

>
> - Heikki

JdV!!

--
--------------------------------------------------------------
Jan de Visser                     jdevisser(at)digitalfairway(dot)com

                Baruk Khazad! Khazad ai-menu!
--------------------------------------------------------------

On Wed, 7 Dec 2005, Jan de Visser wrote:

> Great. So shall I clean up my patch (error messages etc) and send it here? Or
> how does that work? I'd also like to submit my changes to BaseDataSource
> allowing for loglevel to be set...

I'm not a committer, but yeah, that's how it works here. Also add
a test case to the test suite if applicable.

Many thanks for WebLogic testing and the fix!

- Heikki