jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Smuts <asm...@yahoo.com>
Subject RE: JCS as a Hibernate cache provider
Date Fri, 22 Jun 2007 23:34:07 GMT
Ha!  Yes, I have no energy to JBoss bash right now.

Sure, you can simply implement those interfaces and be
on your merry way.  

I have a suggestion to make though.  My suggestion, in
brief, is to do your caching above and not below your
DAOs.  Here's why.

Recently I've worked on several applications that
access data from a variety of sources, xml/http
services, relational databases, flat files, rest style
services, soap services, Java RMI services, etc.  As
your application matures, you will be well advised to
try to break out services so that they can be deployed
and tested largely independently of the rest of the

If you go the service route, or perhaps already need
to get data from a variety of sources and not just a
relational database, then not all of you data could
ever come via an OR mapping tool.  For simplicity's
and consistency's sake I recommend building in a layer
on top of all data access that can handle caching. 
I've been calling this the "manager" layer.  My
services are structured like this, each layer in a
different project:

REST layer
logical Service layer
Manager layer (caching facade)
DAO's (webservice clients and database DAOs in 2
different projects)

All of my object caching is done at the manager layer.
  A single manager can only talk to one and only one
DAO.  And a manager cannot talk to any other manager. 
The manger layer is a simple caching facade.  

There is one important aspect of this layer:  It
transforms the datatypes.  That is, managers are
strictly forbidden to return the value objects that
came from the DAO.  The manager layer provides a true
layer of abstraction.  You don't have an API if you
are returning objects from the DAO.  Often the value
objects will be very similar to those returned by the
DAO, but this is just fine.  Also, only the
transformed objects will be cached.

The transformation is why I call the manager layer a
"facade" and not a "proxy."  Having this facade in
place allows you to do fantastic things like switch
datasources from a database to another or to a
webservice without modifying anything above.  I've
done this several time.  If you passed up the database
DAO's objects, then if you changed to a webservice for
data access, you'd have to change everything above. 
(Using a shared value object package is a terrible
idea.  It gets you horizontal smear.)

I also transform at the logical service layer. 
Services can talk to other services, but they all have
their own return types.  This extra layer of
abstraction increases testablity and reduces
fragility.  But this is for another story.

I haven't described a "hello world" style pattern. 
This is more of a recipe for how to keep a giant
application clean.  Although you can cache in
hibernate with JCS, I wouldn't.

Aaron Smuts

--- Tim Cronin <tcronin@interwoven.com> wrote:

> Don't get Aaron  started! :D
> We use JCS instead of EHchache
> you just need to implement the 
> org.hibernate.cache.Cache and
> org.hibernate.cache.CacheProvider
> -----Original Message-----
> From: Niall Gallagher [mailto:niall@switchfire.com] 
> Sent: Friday, June 22, 2007 1:15 PM
> To: JCS Users List
> Subject: JCS as a Hibernate cache provider
> Hi All,
> What is the state of play on using JCS as a
> Hibernate distributed
> second-level cache? Is it possible to configure
> this?
> I note on the Hibernate website that there is some
> out-of-date
> documentation on configuring JCS as a cache provider
> in Hibernate 2.
> Since then it seems JCS has fallen out of favour
> with Hibernate
> developers. I don't see why. There does not seem to
> be an alternative
> cache provider for Hibernate, which provides
> distributed cache
> functionality like JCS does. Apart from Coherence,
> which seems extremely
> expensive.
> There are several distinct subsystems within this
> company -
> inbound/outbound message interfaces (A), message
> processing systems (B),
> web servers (C). We have common code which is shared
> between all systems
> - user account objects, lookup data objects etc.
> Each subsystem also has
> its own subsystem-specific set of objects however.
> We want a distributed cache to allow subsystem C to
> access user account
> and lookup data objects added to the cache by
> subsystem A. We do not
> want subsystem C to receive replicated cache data
> for objects only
> needed by subsystem A however. Thus we can't just
> configure every
> subsystem on our network to be in the same cluster,
> as it would flood
> our network with pointless traffic. We need to
> segment our data so data
> stored in some cache regions is propagated or
> accessible only to
> specific subsystems, but data stored in other cache
> regions is
> accessible to all systems company-wide. JCS supports
> this sort of
> configuration and it's why we are using it.
> The apparent downside to JCS however, is that it's
> not documented as
> capable of being configured as a Hibernate 3.2
> second level cache, and
> we load most of our data from databases using
> Hibernate. To store
> Hibernate objects in the JCS cache, we are having to
> avoid defining the
> relationships between our Hibernate persistent
> classes (i.e. specify the
> relationships between the DB tables they represent)
> so that at runtime
> when we try to put a persistent object in the JCS
> cache, it does not
> 'pull' the referenced objects with it.
> If JCS was supported as a Hibernate second-level
> cache directly,
> Hibernate would take care of this "object reference
> problem"
> automatically, as it does for the other caches it
> supports directly.
> Basically, we need the power of JCS as a distributed
> cache, because none
> of Hibernate's other caches are powerful enough, but
> it would simplify
> things for us a great deal if we could just
> configure Hibernate to use
> JCS as a second-level cache.
> Has anyone tried this?
> We are using Hibernate 3.2 with
> Hibernate-annotations for accessing the
> DBs. We have written some "JCS annotations" which we
> use to configure
> JCS regions on-the-fly using a JCS wrapper interface
> we have written.
> This allows us to specify the type of JCS caching we
> want per-class
> using annotations (e.g. lateral/clustered vs.
> company-wide distributed).
> Any information on JCS + Hibernate would be
> appreciated.
> Kind regards,
> Niall
> ____________________________________
> Niall Gallagher
> Senior Developer / Architect 
> Switchfire Ltd. 
> phone: 
>               + 44 (0)20 7798 2807  
> fax: 
>               + 44 (0)20 7798 2801  
> email: 
>                niall@switchfire.com 
> web: 
>                  www.switchfire.com 
> To unsubscribe, e-mail:
> jcs-users-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> jcs-users-help@jakarta.apache.org

To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org

View raw message