[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