Issue Details (XML | Word | Printable)

Key: GLASSFISH-3916
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Rebecca Parks
Reporter: burdeasa
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
glassfish

[UB]Resource Adapter call to XATeminator.recover hangs if automatic recovery is enabled

Created: 13/Dec/07 08:21 AM   Updated: 06/Jun/11 04:25 PM   Resolved: 12/May/11 02:00 PM
Component/s: docs
Affects Version/s: 9.1pe
Fix Version/s: 3.1.1_b06

Time Tracking:
Not Specified

Environment:

Operating System: All
Platform: All


Issuezilla Id: 3,916
Status Whiteboard:

v3_excluded

Tags: 3_1-release-note-added 3_1-release-notes
Participants: burdeasa, Jagadish, marina vatkina, Paul Davies, Rebecca Parks, sanandal, sankara, scatari, Scott Fordin and Sivakumar Thyagarajan


 Description  « Hide

See forum post:
http://forums.java.net/jive/thread.jspa?threadID=34201&tstart=0

I am the developer for a JCA 1.5 resource adapter named DTPRA. Note that DTPRA
works with WebSphere Application Server, WebLogic Application Server and JBoss
Application Server.

I needed to test DTPRA with the Sun App Server, so I downloaded Sun Java System
Application Server Enterprise Edition 9.1 (build b58g-fcs) to test DTPRA.

I am now testing transaction recovery, so I set automatic recovery to true.
That is, I have the following in my domain.xml:

<transaction-service automatic-recovery="true" heuristic-decision="rollback"
keypoint-interval="65536" retry-timeout-in-seconds="600" timeout-in-seconds="0"
tx-log-dir="${com.sun.aas.instanceRoot}/logs"/>

When I start the App Server with this setting, the App Server hangs and it
never starts.

Looking at trace output from DTPRA, it is clear that the following has happened:
1) The App Server called the ResourceAdapter.start method for DTPRA.
2) As part of DTPRA startup, DTPRA calls the App Server's XATerminator.recover
method to see if there are inbound transactions to recover.

The call to XATerminator.recover never returns. Apparently there is some sort
of deadlock in the App Server when a resource adapter calls
XATerminator.recover from the ResourceAdapter.start method.

This only occurs when automatic recovery is enabled.



Sivakumar Thyagarajan added a comment - 14/Dec/07 03:17 AM

Thanks for filing this issue. Assigning to Jagadish to investigate further.


Jagadish added a comment - 09/Jan/08 10:28 PM

assigning the issue to Sankar


Jagadish added a comment - 09/Jan/08 10:30 PM

needs evaluation in jts module


sankara added a comment - 14/Feb/08 07:45 PM

Present Architecture doesn't allow any transactional activity till the
transaction recovery is completed and file based transaction logs are cleaned
up. It will be a big change to support in current release and will be targeted
for V3.


marina vatkina added a comment - 20/Jun/08 06:08 PM

Reassign


sanandal added a comment - 11/Jan/09 07:01 AM

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."


marina vatkina added a comment - 23/Sep/09 05:36 PM

Post v3


marina vatkina added a comment - 17/May/10 03:04 PM

Will look into it...


marina vatkina added a comment - 04/Oct/10 12:49 PM

With all the latest changes this seems to be fixed in 3.1. Please reopen if
there is an exact scenario that causes any problems.


Jagadish added a comment - 27/Jan/11 08:54 AM

After talking to Marina, re-opening and marking this issue for release-notes.

" It is not advisable to do transactional activity (eg: starting a transaction / calling XATerminator.recover) during ResourceAdapter.start()). "

Refer the original thread for more details :

http://markmail.org/message/ogc7qndhaywfkdrp#query:+page:1+mid:kyyzpcexusbnv7ri+state:results

Recently, we have encountered the following issue :
http://java.net/jira/browse/GLASSFISH-15677
Though we propose to fix the above issue ( GLASSFISH-15677 ), there are other use-cases that might result in similar deadlock as stated in this issue ( GLASSFISH-3916).


marina vatkina added a comment - 27/Jan/11 09:42 AM

We have 2 choices:
a) RN it
b) Document in 2 chapters - Transactions and Connectors - to get attention of all users


Paul Davies added a comment - 04/Mar/11 10:10 AM

As this issue is included in the 3.1 Release Notes, the fix in the base documentation can be deferred until 3.2.


Scott Fordin added a comment - 15/Apr/11 06:35 PM

Added topic to 3.1 Release Notes.


Rebecca Parks added a comment - 12/May/11 02:00 PM

Added the Release Notes info to the Administration Guide's chapter on transactions, specifically the section on recovery limitations.


scatari added a comment - 06/Jun/11 04:25 PM

Fixing the target version to include the correct build number.