|
As a follow-up to this question, I have just found out that specifying the new v12 HOST connection parameter forces local connections to use TCP/IP instead of Shared Memory. I was not aware of that... Reading the docs, I've noticed it is documented that way, and that HOST is primarily meant for connections to remote machines. However, the following quote
does not clearly tell that local connections will then use TCP/IP instead of shmem. And the following quote from the CommLinks parameter doc page seems to recommend HOST as well:
Question: Is there a way to specify HOST and still use shared memory locally? When migrating to v12, I have understood the introduction of the HOST connection parameter primarily as a means to improve over the former usage of "LINKS={TCPIP(HOST=...)" options, and to add it to the existing ENG/Server parameter. So I made of use it in typical ODBC DSNs that are used identically on several boxes - including the one where the engine is running. - Now I think that for the applications on the engine box itself, that has not been an improvement... I'm not quite sure if I'm primarily asking a question or trying to hint at a better documentation of the side effects or just giving a warning... |
|
Specifying LINKS=TCPIP{host=some-host-name:2638;DoBroadcast=None;Verify=No} and specifying LINKS=TCPIP{host=some-host-name:1234;DoBroadcast=None;Verify=No} and using LINKS=TCPIP{host=some-host-name:1234;DoBroadcast=None;Verify=Yes};servername=myserver so as a side effect of using the HOST connection parameter you are indicating that you want to use TCP/IP. There is currently no method of using the HOST connection parameter and still use shared memory locally. This is an interesting possibility as an enhancement for a subsequent release and we will consider it. Mark, that's a great documentation enhancement, particularly as there has been some confusion between the HOST connection parameter and the HOST protocol option - please add this to DCX... Given this explanation, I think the "recommendation to use HOST" in the docs should be more precise: It should clearly point out that "you are indicating to use TCP/IP" and that this is not generally recommended for local connections.
(09 Mar '12, 09:18)
Volker Barth
Replies hidden
1
@Volker: I've sent a message to the doc team ... We'll see what we can do.
(09 Mar '12, 09:27)
Mark Culp
1
Choosing to use the same keyword HOST for a connection parameter as well as the network connection parameter, while giving it new and different functionality, was a HUGE MISTAKE. It isn't just the name, however... the very existence of the HOST connection parameter was a mistake... it wasn't needed, and it serves only to obfuscate, not simplify. Fortunately, folks can avoid the confusion ("is it Verify Yes or Verify No?") by choosing to NEVER USE the HOST connection parameter... use LINKS instead. LINKS works just fine, without the obfuscation.
(09 Mar '12, 09:29)
Breck Carter
Replies hidden
To add another issue: My previous misunderstanding is surely influenced by the fact that specifying ENG or Server has always been "good" both for local and remote connections, i.e. it would do "no harm" for local connections even if it would not have been necessary. In the way, the HOST connection parameter seems to behave differently, and that's a relevant difference, methinks. (Yes, I'm aware that local TCP/IP connections do work, so using them is simply sub-optimal.)
(09 Mar '12, 09:37)
Volker Barth
@Breck: Well, I guess while writing the "SQL Anywhere 12 TOP 10" document your point of view was different, wasn't it - "HOST is no more a mere hint to the host name / IP address to use but a true specification..." (in my words)... Besides that, I agree with your point: For folks used to the LINKS parameter, the new behavour is at least surprisingly...
(09 Mar '12, 09:44)
Volker Barth
|
