[Mulgara-dev] ConnectionFactory caching strategy
Alex Hall
alexhall at revelytix.com
Thu May 8 18:28:34 UTC 2008
I've been making extensive use of the Connection API of late, and have
encountered some issues that make me think it's time to revisit the
caching strategy used by the ConnectionFactory class. The strategy used
right now is straightforward: the factory maintains a map of server URI
to Connection object, and the first time a connection is retrieved for
that particular server it is added to the map. (A similar cache is
maintained which maps Session to Connection, but a client that is
retrieving Connections via a Session object has already taken on the
responsibility of Session management so I think this falls outside the
scope of this discussion). The next time a Connection is retrieved for
that same server URI, the cached Connection is returned. This approach
has the advantage of avoiding the overhead of setting up a new RMI
connection each time. However, I have encountered the following
specific issues with this implementation:
1. If one client gets a connection from the factory using the server
URI, operates on the connection, and closes it, then the next client to
get a connection to the same server URI will receive a connection that
is closed and therefore unusable. This bug has been logged in Trac as
ticket 106 [1].
2. I am concerned that the RMI Session backing a connection to a remote
server might time out if enough time elapses between successive client
calls to the factory to get a connection.
3. I can think of cases where the calling code might want to get a
Connection that is not shared with others. Specifically, I am thinking
of a multi-threaded application where the calling code will want to get
a connection, turn off auto-commit, modify a graph, and commit its
changes without interference from other threads.
Addressing the first two issues should not be all that difficult; it
should be fairly straightforward to check a Connection after getting it
from the cache and discarding it if it has been closed or timed out.
Addressing the third issue is slightly more involved. The easiest
implementation would be to provide a new method in ConnectionFactory to
get a new connection that is not cached, but heavy use of such a method
would lose the benefits that caching provides. A better way might be to
maintain information in the cache about which thread is currently using
a connection, and not allow any connection to be in use by multiple
threads simultaneously. In this case, a new method could be added to
release a connection for use by other threads without explicitly closing
it, which would keep some of the benefits of caching.
I can implement any necessary changes to the factory since it's
important for the work I'm doing. I just wanted to open this up for
conversation before I start coding away. Please let me know if you have
any thoughts on the subject.
Regards,
Alex
[1] http://mulgara.org/trac/ticket/106
More information about the Mulgara-dev
mailing list