[jbosscache-dev] Fwd: hibernate-dev Digest, Vol 9, Issue 88
From the Hibernate dev list, from yesterday, detailing out Steve's
plans for refactoring in HIbernate, wrt. 2nd level caches:
Begin forwarded message:
> From: hibernate-dev-request(a)lists.jboss.org
> Date: 28 March 2007 21:08:02 BDT
> To: hibernate-dev(a)lists.jboss.org
> Subject: hibernate-dev Digest, Vol 9, Issue 88
> Reply-To: hibernate-dev(a)lists.jboss.org
>
> <SNIP />
>
> Message: 2
> Date: Wed, 28 Mar 2007 15:07:38 -0500
> From: Steve Ebersole <steve(a)hibernate.org>
> Subject: [hibernate-dev] org.hibernate.cache redesign
> To: hibernate-dev <hibernate-dev(a)lists.jboss.org>
> Message-ID: <460ACB0A.4010205(a)hibernate.org>
> Content-Type: text/plain; charset="iso-8859-1"
>
> So I am in the midst of redesigning the stuff in the
> org.hibernate.cache package
> as we discussed previously during our last roadmap discussion.
> This is work I
> will commit to trunk, but not to Branch_3_2 and which will start
> the 3.3
> development line since it will require significant SPI changes.
>
> So I just wanted to start a more detailed discussion regarding my
> plans here and
> to see if anyone wants to add anything and to make sure I am not
> missing anything.
>
> So the first aspect is to split and rename the concept which is
> currently termed
> org.hibernate.cache.Cache. Now, there will be a base interface named
> o.h.c.Region, with 4 specializations: EntityRegion, CollectionRegion,
> QueryResultsRegion, TimestampsRegion (whose purpose are hopefully
> self-evident :)
>
> Next, we need a SPI for building these various types of regions.
> This is the
> role of the new o.h.c.SecondLevelCache interface. It is somewhat
> akin to
> o.h.c.CacheProvider in terms of contract except that I break out
> different
> methods for building each "region type". Currently there is one
> implementation
> OOTB: o.h.c.impl.SecondLevelBridge which acts as a bridge between
> this new API
> and the older CacheProvider stuff, which I decided to leave in
> place for the
> time being to make migration easier initially. But this is where,
> for example,
> we'd plug in more intelligent region management like we have been
> discussing
> with the JBossCache team.
>
> These changes also affect how o.h.c.CacheConcurrencyStrategy
> works. First, I
> took this refactoring as an opportunity to rename
> CacheConcurrencyStrategy to
> AccessStrategy since that is more true to the role. And actually
> this is split
> as well into EntityRegionAccessStrategy and
> CollectionRegionAccessStrategy,
> because I found this more natural and easier to follow from an
> implementation
> perspective (I did not really see a philosophical reason for this
> split).
>
> Anyway, I attached the initial version of these contracts for an
> early peek.
>