iNTERFACEWARE™ Inc.

Multi-Threaded Applications

The rule for each instance of a Chameleon engine in your code is that only one thread should use each engine at a time. Your code should not attempt to directly persist Chameleon table/message objects beyond the lifetime of a message event.

If your code does do any of the above you will see some very odd looking error messages.

To avoid these errors you should either put a synchronization object around your engine objects or change your application design to be such that only one thread goes through each engine.

We could alter Chameleon's design to make each engine instance thread safe by putting a synchronization object around the engine. This would make the product slower and impose a performance penalty on customers who do not require each engine instance to be thread safe.

Another approach that could be followed to make Chameleon engine objects generically thread safe would be to create all the data structures required to parse a message every time the parse method is invoked. This would have the unacceptable consequence of greatly slowing down the engine because allocating and de-allocating memory is a computationally slow operation. Currently Chameleon achieves high performance by having each engine instance reuse a large number of internal data structures, thus avoiding unnecessary memory allocation.

In general, developers do not clearly think through the issues in multi-threaded design. To help you think through the design issues in this regard, it's recommended that you read the discussion on how to intelligently apply multi-threading in the design issues with the HL7 interfaces section of the manual.