[Quickfix-users] QuickFIX/J newbie needs tips on robustness

[Scott M. <dl....@gm...>]

I'm a FIX (and QuickFIX) newbie, using QuickFIX/J to write a simple
trading application.  The basic system design includes a database into
which pending orders are written, and my application, which
periodically sweeps the database, placing any pending orders.

Naturally, I want to ensure that orders aren't placed twice (because
they'll appear to the broker as two separate orders), so after sending
the order message to the broker, my application updates the database
to say that the order has been sent.  Later, when the order is
accepted or rejected by the broker, the database will be updated again
to say so.

One concern I have is this: suppose the power goes out (or pick your
favorite disaster) after the order message has been sent but before
the database has been updated to say it was sent.  Now, when my
application wakes up again, it will think the order was never sent,
and will (re-)send it to the broker.

Realizing this, I attacked the problem in two parts.  First, I changed
the code to do things the other way around: flag the order as sent,
then send the order message.  Second, when my application starts up,
it looks at all orders flagged as sent (but not yet acknowledged by
the broker) and resends them with PossResend=Y.

That seemed great -- except that it turns out that my particular
broker doesn't support orders with PossResend=Y.

*Sigh*.

So I changed it again: now, when my application starts up, it sends an
OrderStatusRequest for the order, which should result in an
ExecutionRpt giving the order's status; I figured that if my broker
indicated they'd never heard of the order, I should re-send it.

That seemed great -- except that it turns out that my broker rejects
OrderStatusRequest unless it includes their OrderID (not ClOrdID), and
you don't get their OrderID until you've received the acknowledgment
to your order request.  And the orders I'm worried about are precisely
the ones for which I don't have that information, because the power
went out at the wrong time.

I ran into the same problem (my broker demands an OrderID I don't yet
have in the case I care about) when I tried to use OrderCancelRequest,
and when I tried to use OrderCancelReplaceRequest.  I couldn't find
anything else promising in the FIX spec, and am now officially out of
ideas.

So, O wise and experienced FIX folks, how would you solve this
problem?  Is there a way to write my application so that it will
robustly recover from the state I'm concerned about?  My broker
supports FIX4.2, if it matters.  (Though not as completely as I would
like, as you can see. ;-)

-- 
"Life results from the non-random survival of randomly varying
replicators." -- Richard Dawkins