Hi Ben, answers inline:
> - Change the RequestTransactionManager class so that it processes the > requests in the transaction ID order instead of the submitted order. This wouldn’t solve the problem because how would the manager know that there is a latter message inbound with a lower transaction id. (I mean you could loop/sleep for a required id but that sound inefficient) > - Create a class that retains the transaction id order. Same problem as above. Its not really about the order > - Modify the RequestTransactionManager to have the option between the > two. As both options don’t solve the issue from my understanding you need something different. > > I'd prefer modifying the existing class to use the transaction id order, > but don't know enough about the other protocols PLC4X supports to say that > it won't affect them. > > Kind Regards > > Ben For me it sounds a bit like you would need to get control over over your threads and/or use a pooled connection. Root cause is that the creation of the transaction and the scheduling is decoupled and here you get the race condition. Another way to solve this is to use a mutex that gets opened when a transaction is opened and closed when the message is queued. As you said this is related to OPCUA its fine to add this to the protocol logic there. Sebastian
