You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jcs-users@jakarta.apache.org by Niall Gallagher <ni...@switchfire.com> on 2007/06/22 20:14:38 UTC
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
RE: JCS as a Hibernate cache provider
Posted by Aaron Smuts <as...@yahoo.com>.
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
application.
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 <tc...@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
RE: JCS as a Hibernate cache provider
Posted by Tim Cronin <tc...@interwoven.com>.
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