[Mulgara-dev] ItqlInterpreter.isLocal problem

[Andrae Muys]

On 01/10/2006, at 5:25 PM, Life is hard, and then you die wrote:
> This seems wrong: why would the local'ity of the previous server URI
> necessarily have anything to do with the locality of a new server URI
> being set?
>
> Now, there are in fact two places where isLocal is being used. First
> in updateSession(), as follows:
>
>     serverURI = SessionFactoryFinder.findServerURI();
>
>     SessionFactory sessionFactory =
>         SessionFactoryFinder.newSessionFactory(serverURI, !isLocal);
>
> Since findServerURI() always returns a local URI, it would seem to
> make more sense to just use
>
>         SessionFactoryFinder.newSessionFactory(serverURI, false);
>
> The second case is in setServerURI(). Here I'm thinking the best
> option would be to either A) add a isRemote or isLocal parameter to
> the setServerURI() method, or B) to try to guess the value from the
> hostname using something like
>
>     String host = databaseURI.getHost();
>     boolean isLocal =
>         NetworkInterface.getByInetAddress(InetAddress.getByName 
> (host)) != null;
>
> Does this make any sense? Am I missing something?

I believe the isLocal flag is used to avoid loops when implementing  
the RemoteResolver.  Paul is the best person to correct me in this,  
but IIRC the serverURI is not always local when working with  
distributed queries.  As the RemoteResolver was never released in  
Kowari (it was a proprietary feature of TKS, the closed-source  
version), this is not immediately apparent in Mulgara.  OTOH,  
implementing a basic RemoteResolver is a relatively straight forward  
proposition should anyone require it, and so it is probably best if  
we don't remove the infrastructure required to support it.

That it is causing you trouble is of concern, if Paul (or someone  
else) hasn't been able to look at it by the time I have transactions  
in hand, I'll see what I can do.

> FYI, the specific problem we're running into is that we're exporting
> ItqlInterpreterBean via SOAP. Because isLocal defaults to false, and
> because we're not running an RMI server (or registry) the calls all
> fail (we're using "rmi://localhost/server" as the server URI).

Brian can probably comment here, but I thought that with the new  
model URI/URN disambiguation code an rmi protocol in the URI always  
attempted an RMI call.  So maybe the problem isn't the isLocal flag.   
Have you tried "local:server#", 'local' is the nominated protocol for  
accessing an embedded server.  Local here means 'in-process', so if  
you are accessing via soap or rmi then !isLocal is correct.

HTH,

Andrae

-- 
Andrae Muys
andrae at netymon.com
Principal Mulgara Consultant
Netymon Pty Ltd