[Mulgara-dev] Database and SessionFactory issues

Alex Hall alexhall at revelytix.com
Tue May 20 14:35:19 UTC 2008


In recent posts to this list, Ronald has expressed his unhappiness with 
the SessionFactory architecture, and I share this sentiment.  In an 
offline conversation, Paul asked me for a list of specific issues that I 
have.  In the interest of giving him something more to work with than 
"It's broken and needs refactoring," here is my list of specific issues 
related to SessionFactory that bothers me.  It is by no means meant to 
be exhaustive, it is just a collection taken from my personal 
experience.  Please comment on or add to it as you see fit.

1. Canonicalization of server URI's.  There are too many places 
throughout the code that are trying to do hostname aliasing, with the 
end result being that in any one place there's no good way of knowing 
what the expected form of the server URI will be.  This results in 
issues such as the one cited by Ronald, where a server URI obtained from 
one place cannot be used with SessionFactoryFinder to connect to the 
database.  This issue is closely related to the conflation of URI and 
URL; once the database URI is decoupled from its location, there is no 
need to convert it to canonical form.

2. SessionFactory classes take URI's instead of URL's.  Once again, 
resolving this depends on decoupling the logical database URI from its 
physical location.  I think that the argument to a SessionFactory should 
be a URL that describes the location of a server, not the URI that 
describes the identity of the server.  This in turn might dictate the 
need for a mechanism of converting from database URI to server URL to 
support certain applications.

3. SessionFactoryFinder falls back on LocalSessionFactory if an RMI 
connection on localhost fails.  This has the unpleasant side effect of 
attempting to start up an entire new Database.  The way I see it, if I 
want to connect to a server using a URI with a scheme of "rmi://" that 
means I know there is a remote server running at that location.  It 
*doesn't* mean that I want an embedded database to be instantiated in 
the local JVM if no server is running at that location and the location 
happens to be on my local machine.  I expect to get an error if this is 
the case.

4. LocalSessionFactory *always* attempts to instantiate a new Database. 
  It has a static SessionFactory field that it tries to initialize with 
a new triple-store implementation the first time that newSession is 
called.  It does not have knowledge of any other Database instances 
which might be present in the JVM (either through EmbeddedMulgaraServer 
or direct use of the Database class) so it always tries to create a new 
one, which in turn raises errors if one already exists.  I think the 
semantics of the newSession operation should be to connect to an 
existing local Database with the given URI.  If the client wishes to use 
a local Database, they should configure it directly instead of relying 
on its creation as a side effect of a call to the newSession method.

5. The triple store implementation class is configurable.  In theory, 
this might be a nice feature to have, but in reality are we really going 
to have an alternate implementation class to Database?  Making the class 
name configurable and using reflection to invoke it when it can only 
have one value only makes for obtuse code, and possibly interferes with 
our ability to effectively configure the Database.

6. EmbeddedMulgaraServer needs to go away.  It is unreadable and it 
makes my head hurt trying to decipher anything that is going on in 
there.  There are at least 2 or 3 objects called "server" and it's hard 
to tell what any of them is doing.  There is no way that class should be 
starting up a Jetty server, but that's what it does.  As Paul has said, 
it needs to be replaced altogether with a set of modularized services 
and components that the developer can configure as he sees fit.  It is 
relatively isolated from the other issues here, but related enough that 
I think it should be done in concert with any serious refactoring of the 
SessionFactory framework.

Regards,
Alex



More information about the Mulgara-dev mailing list