[ http://jira.jboss.com/jira/browse/JBTM-355?page=comments#action_12409069 ] Andrew Dinn commented on JBTM-355: ---------------------------------- Can you please explain why the value of this timeout needs to be configured with a larger value and how this value relates to your transaction's 'size'? Also, by 'size' are you referring to the number of participants or the amount of work done by each participant? The transport timeout is only ever employed when dispatch of a WS-C/T protocol message must wait on receipt of a corresponding protocol message. For example, the WS-AT Coordinator engine responds to a prepare request by sending a PREPARE message to the participant and then waiting for a PREPARING message to be returned in response. Processing of the incoming message and dispatching the corresponding response will normally happen very quickly as it only involves a small amount of work on the part of the transaction system. The other variables in the equation are the communication transport delays and, in some cases, a certain amount of processing time added by the participant implementations (in the example above the participant's prepare method will be invoked). The participant may conceivably be delaying the response for more than 30 seconds. If so then this is likely to be due to an error in the participant. -- 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

[ http://jira.jboss.com/jira/browse/JBTM-355?page=comments#action_12409567 ] Andrew Dinn commented on JBTM-355: ---------------------------------- I'm still not convinced that configuring this timeout is the correct thing to do. Can you explain i) which database you are using and ii) what your code is doing in the prepare call? I am assuming that this problem arises because entities created in your subordinate TX only get flushed at prepare time due to the delegation involved in bridging. The persistence manager install a Syncrhonization to flush cached SQL updates to the database. This normally runs before the 2PC is entered but with bridging the flush cannot be performed (i.e. the Synchronization cannot be executed) until the delegated prepare arrives which stalls the parent TX. One possibility might be for you to manually flush changes inside your EJB code as you make them. This should leave little or no work to do at prepare time because the DB updates will already be out on disk. Can you try this? Another option might be to do break the create operations into lots of little transactions. Do you have to do this update all in one go? Anyway leaving these questions aside for the moment, if you want to reset the timeout you can easily do so by invoking TransportTimer.setTransportTimeout(long) from your application code. -- 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

[ 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. -- 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