[Mulgara-dev] ConnectionFactory updates

Life is hard, and then you die ronald at innovation.ch
Wed May 21 19:50:51 UTC 2008


On Tue, May 20, 2008 at 07:56:29PM -0400, Alex Hall wrote:
> I've made updates to the ConnectionFactory class (and Connection 
> interface) to support concurrent use by multiple clients.  I'm running 
> the tests tonight and should be committing the changes tomorrow, just 
> wanted to give everybody a preview of the changes.  Note that 
> "Connection" is an interface and "SessionConnection" is its implementing 
> class; I use the terms somewhat interchangeably here and I apologize up 
> front for any confusion this may cause.
> 
> The ConnectionFactory allows clients to access Connections based on 
> either server URI or an existing Session.  For accessing Connections 
> based on an existing Session, I eliminated the cache altogether because 
> there is no overhead in creating a new Connection from an existing 
> Session.  When clients access Connections using an existing Session, 
> they are already taking on the task of Session management.
[snip]
> Since the Connection now needs a reference to the factory that created 
> it, I changed the access level on the SessionConnection constructor from 
> public to default access.  The SessionConnection can no longer be 
> created directly by clients; all access should go through the 
> ConnectionFactory class.  If anybody thinks this will be a problem, let 
> me know so we can work on an alternate implementation.

Hmm, we've not been using ConnectionFactory at all but instead are
creating SessionConnection's directly. But I think with the change to
not cache connections based on explicit Session's, and with the change
to be able to dispose Connection's and thereby close the underlying
Session, we should be ok with switching to ConnectionFactory.
(Basically we cache things at a higher level, so we expect to be able
to manage things ourselves, i.e. we don't want the caching done by
ConnectionFactory).

> Note that while the ConnectionFactory class is synchronized for 
> concurrent access by multiple clients, the same is not true for the 
> Connections that it returns.  Clients are responsible for managing 
> Connections and restricting their access to a single thread.  Also, it 
> is possible for a client to get a reference to the Session that backs a 
> Connection, close the Connection so the Session is re-used, and continue 
> executing operations on the Session.  Closing that loophole would 
> require a wrapper around the Session and I considered that to be overkill.

I agree.


  Cheers,

  Ronald




More information about the Mulgara-dev mailing list