Question
· Feb 16, 2016

Does InterSystems.Data.CacheClient.dll use TCP/IP via .Net Managed Provider or not?

Recently I came across a very strong statement to the effect that InterSystems.Data.CacheClient.dll library works fast because it does not open a TCP/IP connection, instead it works in the same process as a database. It made me pause for quite some time. Firstly because .Net Managed Provider, which utilises this library, opens TCP/IP connection to the database (and it is stated in the documentation "Using .NET and the ADO.NET Managed Provider with Caché"). And secondly, because as far as I know only eXtreme applications attach themselves to the process. Besides, CacheClient for the most part just implements the functionality of the Caché system and user classes. And in .Net Managed Provider architecture Caché Object Server is responsible for connection to a database.

So who is right and who is wrong? Is it correct to state that CacheClient.dll operates in the same process as a database or is it just inapplicable? Will be really grateful for your thoughts and input.

Discussion (6)1
Log in or sign up to continue

The managed provider uses TCP/IP.

The confusion probably stems from XEP (eXtreme Event Persistence).

XEP for dotNet still has an in-memory and a TCP/IP connection mode.  As Bill indicated we are moving away from the in-memory mode, as we are improving the throughput of the TCP/IP mode. We already deprecated the in-memory connection mode for XEP for Java where the performance is already pretty much the same. The in-memory connection mode has two issues as a) crashes on the client can interfere with the server and b) it does not allow the client to run on a different machine, which is a problem for scaling up.

XEP for .NET does support both in-memory and TCP/IP connections. The client must be on the same machine for in-memory connections but can run remotely for TCP/IP connections. Long-term we will move away from in-process connections, but we haven't taken this step yet for XEP for .NET.

We consider support for .NET Core interesting and are currently evaluating support for it. But it is too premature to promise anything yet.