Don't cache your DeviceConnection in an EventHandler / Eine DeviceConnection sollte man nicht in einem Eventhandler cachen

(German version below / deutsche Version weiter unten)

A while ago I talked to someone who knows BizTalk RFID inside out about that sometimes it just takes too long to open a connection to a device in an EventHandler.

The advice I received was, why not caching the connection to the device in the EventHandler, possibly opening it in the in the Init() method and keeping it open.

Out of respect I gave it serious thought and now seriously recommend NOT to do that.

• When opening the connection in the Init()-method takes too long or has any slight problems, it will mess up starting up the whole process pipeline.
• You would need to build thread safety around it. Though this is not the biggest concern, it is something you should not do.
• There is a reason why a DeviceConnection implements IDisposable and allows you to use the using statement.
• You effectively disable the chance of any other event handler in another process or even in another piece of software, e.g. a webservice, to access the device normally because you are hogging the connection the whole time.
• Connection caching should be implemented by the device provider implementation, because only this piece of software can have appropriate knowledge.
• In my opinion mechanisms like connection pooling should be part of the application stack in fact.

There might be isolated cases where it still makes sense to cache a connection in an EventHandler, but those should be pretty rare.

(German version / deutsche Version)

For einiger Zeit unterhielt ich mich mit jemandem, der/die BizTalk RFID in- und auswendig kennt darüber, dass es manchmal einfach zu lange dauert, in einem EventHandler eine Verbindung zu einem Gerät zu öffnen.

Ich erhielt den Ratschlag, warum ich nicht die DeviceConnection im EventHandler cachen würde und sie vielleicht schon in der Init()-Methode öffnen würde und danach einfach offen lassen.

Aus Respekt gegenüber meinem Gesprächspartner habe ich ernsthaft darüber nachgedacht und empfehle nun sehr ernsthaft, dies NICHT zu tun.

• Wenn das Öffnen der Verbindung in der Init()-Methode zu lange dauert, oder ein kleines Problem dabei auftritt, wird das den Startvorgang für die ganze Prozess-Pipeline stören.
• Man muss um die Verbindung herum eine ordentliche Thread-Safety herum bauen. Auch wenn das nicht das Hauptproblem sein sollte, ist es einfach etwas, was man vermeiden sollte.
• Es gibt einen Grund, warum die DeviceConnection IDisposable implementiert und so das using-Statement zulässt.
• Man entzieht jedem anderen EventHandler in einem anderen Prozess oder auch einer anderen Software, z.B. einem Webservice, die Chance, selbst normal auf das Device zuzugreifen, weil man die ganze Zeit die Verbindung blockiert.
• Eigentlich sollte man Connection Caching in einer Device Provider Implementierung vorfinden, da nur diese "wissen" kann, was das Device wirklich benötigt.
• Meiner Meinung nach sollten Connection Pooling Mechanismen auch bei RFID Teil des Applikationsstack sein.

Es mag einzelne, isolierte Szenarien geben, wo es Sinn machen kann, eine DeviceConnection in einem EventHandler zu cachen, dies sollte aber wirklich ziemlich selten erforderlich sein.