Why should you explicitly open and close shared variable connections?

Question

I'm looking into switching over from the old Datasocket API to the new Shared Variable API for programmatic access to shared variables, and I noticed that LV doesn't seem to have any problems executing Shared Variable Reads & Writes without first opening the connection explicitly. That is, I can just drop in a shared varaible Read VI, wire a constant to the refnum input, and it will work. I'm wondering, then, what benefits are offered by explicitly opening the conenction ahead of time...?
I guess I could see some cases where you want to open all necessary connections in an initialization state of a top-level state machine, particularly if you want to use the "Open & Verify Connection"---so you could jump straight to an error case if any connections fail. But other than that, why else might one want to explicitly open the connections.
And, along those lines, are there any problems with implicitly opening the connections? One reason why I am hesitant to open them explicitly is because for one of our applications, we need to be able to dynamically switch from one variable to another at runtime. It would be nice to just switch the variable refnum (wired to the input of the Read function), without having to manually close out the old connection and open a new one. A quick prototype of this seems to work. But am I shooting myself in the foot by doing so?
Thanks in advance.

Answer 1

I'd expect there's a very small number of people at NI that would know the answer to the detail you're asking for.  But, let's try to extrapolate from this rather old post to see if we can understand what they're forming their impression on.
The shared variable has to have some sort of reference going on in the background.  It looks like they're calling this a connection.  It's how LabVIEW knows where to find this variable on the network.  We can also see this reference certainly exists if we're opening/closing the reference in the explicit method.  You see the connection as just a string referencing the variable by URL.  This "reference" has to be stored somewhere.  No matter how we're looking at this, we're aware there's a reference of some sort stored. 
Now, we'd want to look at what would cause this reference to go away.  If you open/close explicitly, it's easy to see it goes away at the close.  If it's implicit, when would it make sense to close it out?  The VI can't be expected to guess where it's done being referenced and close it out.  This puts us into a situation where the soonest it could close is when the VI ends.  From my experience, references tend to be wiped when you close out LabVIEW.  It's this kind of idea that makes the FGV possible.  I wouldn't be surprised by Morgan's claim here.
If we look at scalability, you're talking about two different topics.  You're talking about adding an extra open, close, read, etc rather than just a few wires.  That certainly would look a mess.  In terms of the dynamic swap that was being discussed, we wouldn't be adding all of those.  The concern would be if enough connections were opened it'd start to behave similar to a memory leak.  This could be something that works with a smaller number of variables.  If you continue to scale, it becomes problematic.  This is why they suggest it's not scalable. 
To your questions:
Does LV allocate some kind of session in memory using that string as a lookup?
It would HAVE to allocate some memory to hold that string.  Otherwise, it'd be pointless to even have the reference. 
Does it reuse that session if other parts of the application reference the same variable, or does it create a unique session for each referencing call to "Read Variable.vi"?
I would expect this to be "it depends."  With the implicit method, I would expect it to open a new reference in each point it isn't wired.  This is similar to int x,y = 5;  x and y share the same value but are their own unique memory location.  If you wire the reference to the other points, it should use the same reference.  This would make more sense to me than the program seeking out any other potential usage of the variable in the application to see if there's already a reference open.  I could be wrong, though.
And what resources does this "connection" actually represent?
At best, this is just the string.  At worst, it's the string and the TCP socket.  I'd lean towards the first.  Opening and closing sockets should be relatively easy in most applications.  But, it also wouldn't surprise me if it holds the socket.
I'm sure others have a better understanding than I do.  But, that's what I'd expect for anything you've asked.