{{Quickfixn}} Placing a lock on Session.SendToTarget

[Grant Birchmeier]

I don't think that's a problem.  I'd want to limit that lock around
order-send usages only.  If your app can also send other messages (e.g.
Market Data Requests, Sec Def Requests, etc), you don't want those sends to
be waiting on some order lock.

On Fri, Oct 10, 2014 at 11:50 AM, Amar Parmar <amar.parmar at octave-im.com>
wrote:

>   Hi,
>
> I had a bug today where a timer call back and a sequential processer both
> sent the same order (same tag 11).
>
> This happened because the callback identified the order as to be sent
> before the sequential handler had updated the status of the order as sent.
> This would rarely happen, but did occur.
>
> My thought was to place a lock around the portion of code that; checks if
> an order is to be sent, sends it and marks it as sent:
>
>                 lock (sendLock)
>
>                 {
>
>                     if (!dictionaryMaps.isWorking[order])
>
>                     {
>
>                         fixOrder.TransactTime = new TransactTime(DateTime.UtcNow,
> true);
>
>                         Session.SendToTarget(fixOrder, Globals.sessionID);
>
>                         dictionaryMaps.isWorking[order] = true;
>
>                     }
>
>                 }
>
>
>
> I believe this would solve by issue, but I am worried that there maybe
> unintended consequence to placing a lock around the SendToTarget method.
>
> Does anyone see any issues?
>
> Thanks,
>
> _______________________________________________
> Quickfixn mailing list
> Quickfixn at lists.quickfixn.com
> http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com
>
>


-- 
Grant Birchmeier
*Connamara Systems, LLC*
*Made-To-Measure Trading Solutions.*
Exactly what you need. No more. No less.
http://connamara.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quickfixn.com/pipermail/quickfixn-quickfixn.com/attachments/20141010/265d7497/attachment-0001.htm>