db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <djen...@apache.org>
Subject Re: Planning for a 10.1 release
Date Thu, 26 May 2005 05:09:58 GMT
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