[Mulgara-dev] adding ResolverFactoryInitializer.getSessionFactory()

[Alex Hall]

Life is hard, and then you die wrote:
[snip]
>> Just thought of something else... you could use the static 
>> ServerInfo.getServerURI() method to obtain the server URI (this field is 
>> set when the RmiServer starts) and send it to 
>> SessionFactoryFinder.newSession().  This ought to get you an 
>> RmiSessionFactory and shouldn't require any changes to Mulgara. 
>> Hopefully Java is smart enough to optimize out the RMI calls within the 
>> same JVM, but I'm not sure about that.
> 
> I wish. This is unfortunately exactly what I've been doing:
> 
>   dbURI = resolverFactoryInitializer.getDatabaseURI();
>   ...
>   sessFactory = SessionFactoryFinder.newSessionFactory(dbURI);
> 
> (I haven't tried ServerInfo, but that's really EmbeddedMulgaraServer
> specific and won't work in any of the scenarios where
> EmbeddedMulgaraServer is not used).
> 
> But one of the problems is that mulgara "normalizes" the hostname
> part, so if the client accesses the server under a name that doesn't
> happen to be what mulgara thinks is the canonical name (e.g.
> "localhost") then there will be an RmiSessionFactory registered under
> the name used by the client, and the lookup using dbURI will result
> in it not finding that session-factory and instead falling back to
> creating the LocalSessionFactory.

You mean resolverFactoryInitializer.getDatabaseURI() doesn't return
the canonical form?  I find that disappointing, although not terribly
surprising.  I also know better than to go off in search of a way to
fix it; that ship sailed long ago...

> Another issue is that for our embedded usage (mostly for testing) we
> instantiate Database directly because the whole SessionFactoryFinder
> et. al. are way to broken to be usable in that setup (for one you
> can't provide your own external config file), so that case will always
> fail.
> 
> The point is, it's all very hacky currently, and I believe the
> cleanest solution is for the resolver to be able to explicitly get a
> handle on its SessionFactory rather than trying some roundabout
> guessing and relying on certain things being singletons.

I agree, it is all very kludgy at the moment and it will likely stay
that way until significant work is done to refactor it.  Given the
current constraints, adding a getSessionFactory method to the
ResolverFactoryInitializer is probably the cleanest route.  As long as
Andrae is satisfied of its correctness with respect to transactions, I
don't have any concerns other than the security issue I mentioned
previously (which may or may not be relevant).

Regards,
Alex