[
http://jira.jboss.com/jira/browse/JBTM-355?page=comments#action_12409704 ]
Andrew Dinn commented on JBTM-355:
----------------------------------
Ok, thanks for the info. I'll reject this issue but I think your program is perfectly
valid and should not need to flush. I'm glad to know this workaround is ok but there
is a real problem here which needs resolving.
The bridge manager probably ought to ensure that synchronizations associated with the JTA
transaction are run during phase zero by intercepting the add synch requests and
registering its own synchronization to invoke them. This will still require a long timeout
but that should be acceptable at phase zero -- the problem with a long timeout at prepare
is that another participant might give up because of a timeout internal to its associated
resource. I'll raise a JIRA for this problem and see if we can do something about
it.
Be able to configure transport timeout in
com.arjuna.webservices.util.TransportTimer from some configuration file
-----------------------------------------------------------------------------------------------------------------
Key: JBTM-355
URL:
http://jira.jboss.com/jira/browse/JBTM-355
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: WS-T Implementation
Reporter: Pavel Kadlec
Assigned To: Andrew Dinn
Fix For: 4.4
The timeout in com.arjuna.webservices.util.TransportTimer is fixed and as far as I know
there is not possible to configure it from configuration file. 30 seconds (default value)
is too short for my purposes, I have large transaction.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira