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.

  • + 1
  • 0
  • 785
  • 6
  • 0

Comments

To my knowledge it use TCP. In fact we moved away from in memory even for Extreme.. in the end the performance differences were slight. Stefan Wittmann can confirm.

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.

Thank you for your answers, guys!

Does it mean that by the end of 2016 we will have TCP only in both .Net and Java?

Java yes, fuzzy for dotNet. It depends how well we can increase the throughput of the TCP/IP mode there.

Any updates for the dotNet status? Docs current version still says "...they use a fast in-memory connection..." and "...must be on the same machine...".

Another question: any plans to support Net Core?

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.