The precise TWS API requirement is that order IDs for new orders shall be "greater than all previous order IDs returned to the client application in openOrder or orderStatus callbacks".
Your nextOrderId method does seem to generate a sequence of increasing numbers, but here a few thoughts:
- I would remove all strategy related aspects from nextOrderId and make it a simple thread-safe incrementing function. And since thread locks are expensive, I'd look for the equivalent in Python to the Java lock-free AtomicInteger. I am not a Python practitioner, but the "atomics" package seems to provides that.
- You need to make sure that the sequence of orderIds is still "Strictly Monotonically Increasing" when your strategies call placeOrder(). What I mean is that you need to avoid situations where a first strategy gets an orderId but does not get to call placeOrder() for a while. In the mean time a second strategy gets a higher nextOrderId and calls placeOrder() before the first strategy can. So you need a lock around the entire sequence of code from where the strategies make Order objects, call nextOrderId() and until all placeOrder() calls are done.
That should suffice to avoid the duplicate orderId issue in multi-threaded order placement scenarios.
But to be absolutely sure, you also want to monitor the orderIds you receive from openOrder() and orderStatus() callbacks and make sure to nudge the counter in nextOrderId() in case you receive orderIds that are higher than the counter in nextOrderId(). That can happen in cases where your client application gets exposed to orders that where placed by other clients or from within TWS or other tools,
闯ü谤驳别苍
?
?
On Sat, Mar 15, 2025 at 12:32 PM, Marco wrote:
Hi All,
I have an issue with orderId assignment. I have a python code where the client is a class and assign orderId to different strategies running in parallel (each strategy implemented in a separate class). When a strategy has to generate an order, it request?the order id calling client member function nextOrderId(). In order to avoid assigning the same id do different strategies I implemented this function as below:
?
?# return next available order id
? ? def nextOrderId(self,stratId):
?
? ? ? ? #locking the assignment and increase of order id to avoid same order id assigned to different strategies
? ? ? ? with self.lockOrderIdIncrease:
? ? ? ? ? ? self.strategyList[stratId].validOrderId = self.order_id
? ? ? ? ? ? self.order_id += 1
? ? ? ? return self.strategyList[stratId].validOrderId
?
where self.lockOrderIdIncrease is a threading Lock object, initialized in the constructor class:
?
self.lockOrderIdIncrease = Lock()
?
and self.strategyList is a list that for each strategy stores the current used order id, while self.order_id contains the last available order id
?
iI have a couple of strategies that can be activated in the same instant and in paper trading in past days I observed 2 times the error “Error 103: Duplicate order id”. Can someone help me? I do not understand why this is happening as the fragment accessing to the current order Id seems to me allowing access to one thread per time, blocking the others
?
thank you in advance
Marco
?
?
