[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