db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dibyendu Majumdar" <dibye...@mazumdar.demon.co.uk>
Subject Re: Planning for a 10.1 release
Date Thu, 26 May 2005 09:10:13 GMT
David,

All the tests (except the join test ) pass with both Oracle and Derby
Embedded driver.

Regards
----- Original Message ----- 
From: "David Jencks" <djencks@apache.org>
To: "Derby Development" <derby-dev@db.apache.org>
Sent: Thursday, May 26, 2005 6:09 AM
Subject: Re: Planning for a 10.1 release


> I took a quick look at Dibyendu's tests and I think they are OK.  I
> would like to know if these tests pass with the embedded xa support.
> Tests 8 and 9 are IMO completely spec compliant but I believe they will
> not pass with the majority of databases claiming xa support.  As such
> it might not be wise to insist on them :-)
>
> One comment I have is that the app servers I have worked with (geronimo
> and jboss) will use this sequence of calls:
>
> xar.start(xid, TM_NOFLAGS);
> xar.end(xid, TM_SUSPEND);
> xar.end(xid, TM_SUCCESS);
> xar.prepare/commit
>
> You might want to add strategically located suspend calls to make sure
> that makes no difference.
>
> As far as connection handles and pooling, the usage in the tests is
> absolutely standard and I'm sure it is what websphere uses also.
>
> Typically with an ejb CMT call, we have the following sequence of
> events:
>
> 1. container starts tx
> 2. ejb obtains a connection handle.  This involves enlisting the
> XAResource associated with the managed connection/XAConnection with the
> current tx. and obtaining a handle from the mc. We can't tell which
> order this occurs in, but it doesn't seem to make a difference in this
> test.
> 3. ejb uses cx handle
> 4. ejb closes cx handle.  There is no way for the connection manager to
> detect this is going to happen...
> 5 mc/XAConnection notifies listeners that the handle was closed.   At
> this time the connection manager could delist/end the XAResource from
> the transaction.
>
> Note the order of steps 4 and 5, which is the same as in Dibyendu's
> tests.
>
> According to my interpretation of the xa spec, it should now be safe
> (no open cx handles and no tx associated with mc) to put the mc back in
> the pool.  However, I believe most "xa" drivers don't let you do this
> but require you to commit the tx first before starting another.
>
> In conclusion, I would recommend experimenting with the end(TM_SUSPEND)
> call, but I think at least tests 1-7 should pass before releasing the
> driver.
>
> Many thanks,
> david jencks
>
> ps. I would be sure you never use the same xid twice.  I think it would
> be entirely appropriate for derby to object if you do.  I didn't see
> the implementation in the Utils class so I'm not sure if your xids are
> unique or not.
>
>
> On May 25, 2005, at 7:34 PM, Jeremy Boynes wrote:
>
> > David's the Geronimo guru on XA.
> >
> > My understanding is that it is legal for a coordinator to delist a
> > resource before the end of a transaction and return it to the pool; it
> > could then be used by another thread (potentially in another
> > transaction) or just closed.
> >
> > However, there are many resource managers out there that do not
> > support this so most app servers (OK, at least Geronimo and from what
> > you say WebSphere) have a mechanism for associating the physical
> > connection with the transaction until it is over.
> >
> > I haven't looked at the bug but we should clearly document how Derby
> > behaves, especially if client and embedded behaviour are different.
> >
> > --
> > Jeremy
> >
> > Kathey Marsden wrote:
> >> Dibyendu Majumdar wrote:
> >>> From: "Kathey Marsden" <kmarsdenderby@sbcglobal.net>
> >>>
> >>>
> >>>> I think the  workaround for DERBY-246, to leave the logical
> >>>> connection
> >>>> open until the end of the global transaction, should be documented
> >>>> in
> >>>> the release notes.
> >>>>
> >>>
> >>> Hi Kathey,
> >>>
> >>> Unfortunately, this is not a workaround. For example, see section
> >>> 4.2 of JTA
> >>> spec which describes how an application server would use logical
> >>> connections.
> >>>
> >>>
> >> Firstly I want to say that I am motivated to get this fixed. I just
> >> don't  think I can get it fixed in the time frame for the 10.1
> >> release. I don't think it should stop the release. The example says:
> >> "The figure that follows illustrates the usage of
> >> JTA. The steps shown are for illustrative purposes, they are not
> >> prescriptive:"
> >> In this example, with our workaround, I think steps 11 and 12 would
> >> move
> >> down to the end.
> >> I talked with the folks that use XA at Websphere. They said.
> >> "in WAS, we don't close the connections until after they are no longer
> >> in  transactions (closing, means put them in the pool to be used by
> >> others)"
> >> So it seems like it is a workaround.    Could you offer a scenario
> >> where
> >> it is not  a reasonable workaround
> >> Perhaps Jeremy has some perspective as well as to the XA impact.
> >> Jeremy?
> >> Thanks
> >> Kathey
> >
>



Mime
View raw message