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 dadade <de...@lmco.com> on 2007/06/21 20:10:43 UTC
Dump Cache Entries in Memory to Index Disk
Hello,
Is there a way (API) to spooled all the cache entries in LRU Memory to Index
Disk?
Your help is appreciate.
Thanks,
--
View this message in context: http://www.nabble.com/Dump-Cache-Entries-in-Memory-to-Index-Disk-tf3960435.html#a11238613
Sent from the JCS - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org
RE: cache corruption
Posted by Tim Cronin <tc...@interwoven.com>.
we see cache corruption when we do a series of cache deletes using the
key chaining mechanism. I'm still trying to track down a reproducible
scenario.
-----Original Message-----
From: Aaron Smuts [mailto:asmuts@yahoo.com]
Sent: Wednesday, February 13, 2008 2:10 PM
To: JCS Users List
Subject: RE: cache corruption
What kinds of unreliability do you see with the
indexed disk cache? I don't know of any.
Aaron
--- Tim Cronin <tc...@interwoven.com> wrote:
> Thanks for the information.
>
> We use 1.5 as well and it would be nice to
> standardize
> on that.
>
> Do you know if the Block Disk Cache is any more
> reliable
> than the indexed it seems like the impl is simpler?
>
>
> -----Original Message-----
> From: Al Forbes [mailto:forbes.al@googlemail.com]
> Sent: Wednesday, February 13, 2008 11:28 AM
> To: JCS Users List
> Subject: Re: cache corruption
>
> The project is not really actively developed - it
> has the features
> most folks require so it's mostly in maintenance
> mode.
>
> If there are defects they are generally very
> difficult to reproduce.
> Personally I do not think it is worth tracking down
> threading/synchronization until we move to jdk1.5.
> We could try using
> the back-ported concurrent library, but I'm not sure
> that offers much
> benefit. With so few changes, any change using the
> standard jdk15
> library could easily be back-ported to the jdk13
> version of JCS.
> Jdk1.5 is already 3.5 years old, so most people have
> upgraded.
>
> But Aaron is the biggest contributor, so it's really
> up to him to
> decide.
>
>
>
> On 13/02/2008, Tim Cronin <tc...@interwoven.com>
> wrote:
> > yes using indexed disk cache.
> >
> > We can't afford to move to DB at this time...
> >
> > Still trying to come up with at scenario to repro
> >
> > I did notice some private members on the caches
> >
> > IndexDiskCache.checkKeyDataConsistency(boolean)
> >
> > LRUMemoryCache.verifyCache()
> >
> > I can reflect into these if the error occurs
> >
> > I don't see any defects In jira only the one
> > about hitting the cache files from different jvms.
> >
> > The project seems quite is it still actively
> developed?
> >
> > -----Original Message-----
> > From: Al Forbes [mailto:forbes.al@googlemail.com]
> > Sent: Tuesday, February 12, 2008 3:11 PM
> > To: JCS Users List
> > Subject: Re: cache corruption
> >
> > Tim,
> >
> > Are you using the disk cache? I had many problems
> with a large disk
> > cache, but nothing since switching to a database
> cache. I suspect my
> > problem had something to do with the shutdown or
> inconsistencies after
> > a forced shutdown.
> >
> > Al
> >
> > On 12/02/2008, Tim Cronin <tc...@interwoven.com>
> wrote:
> > > We use jcs (1.3) in a web application, and over
> time we're seeing
> > where
> > >
> > > two different keys (string based key) point to
> the same object
> > >
> > > say we have key "a" key "b" if I call
> JCS.getCacheElement("a")
> > >
> > > I get the element where the key = "b". I then
> call
> > >
> > > JCS.remove("b") then call JCS.get("b") I get
> null
> > >
> > > but if I call JCS.get("a") I get the object
> cached for "b"
> > >
> > > and subsequent calls to JCS.get("b") now return
> the object.
> > >
> > > only if call JCS.remove("a") will the problem be
> fixed.
> > >
> > > it also seems to "right" itself over time I
> believe if it
> > > get dropped from the cache.
> > >
> > > I was able to see the key mismatch using the
> JCSAdmin.jsp
> > > to interrogate the cache.
> > >
> > > I'm trying to track down exactly when this
> happens.
> > >
> > >
>
---------------------------------------------------------------------
> > > 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
> >
> >
> >
> >
>
---------------------------------------------------------------------
> > 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
>
>
>
>
---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org
RE: cache corruption
Posted by Tim Cronin <tc...@interwoven.com>.
I assume your talking to Al?
for it's the issue below which you responded to.
-----Original Message-----
From: Aaron Smuts [mailto:asmuts@yahoo.com]
Sent: Wednesday, February 13, 2008 2:10 PM
To: JCS Users List
Subject: RE: cache corruption
What kinds of unreliability do you see with the
indexed disk cache? I don't know of any.
Aaron
--- Tim Cronin <tc...@interwoven.com> wrote:
> Thanks for the information.
>
> We use 1.5 as well and it would be nice to
> standardize
> on that.
>
> Do you know if the Block Disk Cache is any more
> reliable
> than the indexed it seems like the impl is simpler?
>
>
> -----Original Message-----
> From: Al Forbes [mailto:forbes.al@googlemail.com]
> Sent: Wednesday, February 13, 2008 11:28 AM
> To: JCS Users List
> Subject: Re: cache corruption
>
> The project is not really actively developed - it
> has the features
> most folks require so it's mostly in maintenance
> mode.
>
> If there are defects they are generally very
> difficult to reproduce.
> Personally I do not think it is worth tracking down
> threading/synchronization until we move to jdk1.5.
> We could try using
> the back-ported concurrent library, but I'm not sure
> that offers much
> benefit. With so few changes, any change using the
> standard jdk15
> library could easily be back-ported to the jdk13
> version of JCS.
> Jdk1.5 is already 3.5 years old, so most people have
> upgraded.
>
> But Aaron is the biggest contributor, so it's really
> up to him to
> decide.
>
>
>
> On 13/02/2008, Tim Cronin <tc...@interwoven.com>
> wrote:
> > yes using indexed disk cache.
> >
> > We can't afford to move to DB at this time...
> >
> > Still trying to come up with at scenario to repro
> >
> > I did notice some private members on the caches
> >
> > IndexDiskCache.checkKeyDataConsistency(boolean)
> >
> > LRUMemoryCache.verifyCache()
> >
> > I can reflect into these if the error occurs
> >
> > I don't see any defects In jira only the one
> > about hitting the cache files from different jvms.
> >
> > The project seems quite is it still actively
> developed?
> >
> > -----Original Message-----
> > From: Al Forbes [mailto:forbes.al@googlemail.com]
> > Sent: Tuesday, February 12, 2008 3:11 PM
> > To: JCS Users List
> > Subject: Re: cache corruption
> >
> > Tim,
> >
> > Are you using the disk cache? I had many problems
> with a large disk
> > cache, but nothing since switching to a database
> cache. I suspect my
> > problem had something to do with the shutdown or
> inconsistencies after
> > a forced shutdown.
> >
> > Al
> >
> > On 12/02/2008, Tim Cronin <tc...@interwoven.com>
> wrote:
> > > We use jcs (1.3) in a web application, and over
> time we're seeing
> > where
> > >
> > > two different keys (string based key) point to
> the same object
> > >
> > > say we have key "a" key "b" if I call
> JCS.getCacheElement("a")
> > >
> > > I get the element where the key = "b". I then
> call
> > >
> > > JCS.remove("b") then call JCS.get("b") I get
> null
> > >
> > > but if I call JCS.get("a") I get the object
> cached for "b"
> > >
> > > and subsequent calls to JCS.get("b") now return
> the object.
> > >
> > > only if call JCS.remove("a") will the problem be
> fixed.
> > >
> > > it also seems to "right" itself over time I
> believe if it
> > > get dropped from the cache.
> > >
> > > I was able to see the key mismatch using the
> JCSAdmin.jsp
> > > to interrogate the cache.
> > >
> > > I'm trying to track down exactly when this
> happens.
> > >
> > >
>
---------------------------------------------------------------------
> > > 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
> >
> >
> >
> >
>
---------------------------------------------------------------------
> > 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
>
>
>
>
---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org
RE: cache corruption
Posted by Aaron Smuts <as...@yahoo.com>.
What kinds of unreliability do you see with the
indexed disk cache? I don't know of any.
Aaron
--- Tim Cronin <tc...@interwoven.com> wrote:
> Thanks for the information.
>
> We use 1.5 as well and it would be nice to
> standardize
> on that.
>
> Do you know if the Block Disk Cache is any more
> reliable
> than the indexed it seems like the impl is simpler?
>
>
> -----Original Message-----
> From: Al Forbes [mailto:forbes.al@googlemail.com]
> Sent: Wednesday, February 13, 2008 11:28 AM
> To: JCS Users List
> Subject: Re: cache corruption
>
> The project is not really actively developed - it
> has the features
> most folks require so it's mostly in maintenance
> mode.
>
> If there are defects they are generally very
> difficult to reproduce.
> Personally I do not think it is worth tracking down
> threading/synchronization until we move to jdk1.5.
> We could try using
> the back-ported concurrent library, but I'm not sure
> that offers much
> benefit. With so few changes, any change using the
> standard jdk15
> library could easily be back-ported to the jdk13
> version of JCS.
> Jdk1.5 is already 3.5 years old, so most people have
> upgraded.
>
> But Aaron is the biggest contributor, so it's really
> up to him to
> decide.
>
>
>
> On 13/02/2008, Tim Cronin <tc...@interwoven.com>
> wrote:
> > yes using indexed disk cache.
> >
> > We can't afford to move to DB at this time...
> >
> > Still trying to come up with at scenario to repro
> >
> > I did notice some private members on the caches
> >
> > IndexDiskCache.checkKeyDataConsistency(boolean)
> >
> > LRUMemoryCache.verifyCache()
> >
> > I can reflect into these if the error occurs
> >
> > I don't see any defects In jira only the one
> > about hitting the cache files from different jvms.
> >
> > The project seems quite is it still actively
> developed?
> >
> > -----Original Message-----
> > From: Al Forbes [mailto:forbes.al@googlemail.com]
> > Sent: Tuesday, February 12, 2008 3:11 PM
> > To: JCS Users List
> > Subject: Re: cache corruption
> >
> > Tim,
> >
> > Are you using the disk cache? I had many problems
> with a large disk
> > cache, but nothing since switching to a database
> cache. I suspect my
> > problem had something to do with the shutdown or
> inconsistencies after
> > a forced shutdown.
> >
> > Al
> >
> > On 12/02/2008, Tim Cronin <tc...@interwoven.com>
> wrote:
> > > We use jcs (1.3) in a web application, and over
> time we're seeing
> > where
> > >
> > > two different keys (string based key) point to
> the same object
> > >
> > > say we have key "a" key "b" if I call
> JCS.getCacheElement("a")
> > >
> > > I get the element where the key = "b". I then
> call
> > >
> > > JCS.remove("b") then call JCS.get("b") I get
> null
> > >
> > > but if I call JCS.get("a") I get the object
> cached for "b"
> > >
> > > and subsequent calls to JCS.get("b") now return
> the object.
> > >
> > > only if call JCS.remove("a") will the problem be
> fixed.
> > >
> > > it also seems to "right" itself over time I
> believe if it
> > > get dropped from the cache.
> > >
> > > I was able to see the key mismatch using the
> JCSAdmin.jsp
> > > to interrogate the cache.
> > >
> > > I'm trying to track down exactly when this
> happens.
> > >
> > >
>
---------------------------------------------------------------------
> > > 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
> >
> >
> >
> >
>
---------------------------------------------------------------------
> > 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
>
>
>
>
---------------------------------------------------------------------
> 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: cache corruption
Posted by Tim Cronin <tc...@interwoven.com>.
Thanks for the information.
We use 1.5 as well and it would be nice to standardize
on that.
Do you know if the Block Disk Cache is any more reliable
than the indexed it seems like the impl is simpler?
-----Original Message-----
From: Al Forbes [mailto:forbes.al@googlemail.com]
Sent: Wednesday, February 13, 2008 11:28 AM
To: JCS Users List
Subject: Re: cache corruption
The project is not really actively developed - it has the features
most folks require so it's mostly in maintenance mode.
If there are defects they are generally very difficult to reproduce.
Personally I do not think it is worth tracking down
threading/synchronization until we move to jdk1.5. We could try using
the back-ported concurrent library, but I'm not sure that offers much
benefit. With so few changes, any change using the standard jdk15
library could easily be back-ported to the jdk13 version of JCS.
Jdk1.5 is already 3.5 years old, so most people have upgraded.
But Aaron is the biggest contributor, so it's really up to him to
decide.
On 13/02/2008, Tim Cronin <tc...@interwoven.com> wrote:
> yes using indexed disk cache.
>
> We can't afford to move to DB at this time...
>
> Still trying to come up with at scenario to repro
>
> I did notice some private members on the caches
>
> IndexDiskCache.checkKeyDataConsistency(boolean)
>
> LRUMemoryCache.verifyCache()
>
> I can reflect into these if the error occurs
>
> I don't see any defects In jira only the one
> about hitting the cache files from different jvms.
>
> The project seems quite is it still actively developed?
>
> -----Original Message-----
> From: Al Forbes [mailto:forbes.al@googlemail.com]
> Sent: Tuesday, February 12, 2008 3:11 PM
> To: JCS Users List
> Subject: Re: cache corruption
>
> Tim,
>
> Are you using the disk cache? I had many problems with a large disk
> cache, but nothing since switching to a database cache. I suspect my
> problem had something to do with the shutdown or inconsistencies after
> a forced shutdown.
>
> Al
>
> On 12/02/2008, Tim Cronin <tc...@interwoven.com> wrote:
> > We use jcs (1.3) in a web application, and over time we're seeing
> where
> >
> > two different keys (string based key) point to the same object
> >
> > say we have key "a" key "b" if I call JCS.getCacheElement("a")
> >
> > I get the element where the key = "b". I then call
> >
> > JCS.remove("b") then call JCS.get("b") I get null
> >
> > but if I call JCS.get("a") I get the object cached for "b"
> >
> > and subsequent calls to JCS.get("b") now return the object.
> >
> > only if call JCS.remove("a") will the problem be fixed.
> >
> > it also seems to "right" itself over time I believe if it
> > get dropped from the cache.
> >
> > I was able to see the key mismatch using the JCSAdmin.jsp
> > to interrogate the cache.
> >
> > I'm trying to track down exactly when this happens.
> >
> >
---------------------------------------------------------------------
> > 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
>
>
>
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org
Re: cache corruption
Posted by Al Forbes <fo...@googlemail.com>.
The project is not really actively developed - it has the features
most folks require so it's mostly in maintenance mode.
If there are defects they are generally very difficult to reproduce.
Personally I do not think it is worth tracking down
threading/synchronization until we move to jdk1.5. We could try using
the back-ported concurrent library, but I'm not sure that offers much
benefit. With so few changes, any change using the standard jdk15
library could easily be back-ported to the jdk13 version of JCS.
Jdk1.5 is already 3.5 years old, so most people have upgraded.
But Aaron is the biggest contributor, so it's really up to him to decide.
On 13/02/2008, Tim Cronin <tc...@interwoven.com> wrote:
> yes using indexed disk cache.
>
> We can't afford to move to DB at this time...
>
> Still trying to come up with at scenario to repro
>
> I did notice some private members on the caches
>
> IndexDiskCache.checkKeyDataConsistency(boolean)
>
> LRUMemoryCache.verifyCache()
>
> I can reflect into these if the error occurs
>
> I don't see any defects In jira only the one
> about hitting the cache files from different jvms.
>
> The project seems quite is it still actively developed?
>
> -----Original Message-----
> From: Al Forbes [mailto:forbes.al@googlemail.com]
> Sent: Tuesday, February 12, 2008 3:11 PM
> To: JCS Users List
> Subject: Re: cache corruption
>
> Tim,
>
> Are you using the disk cache? I had many problems with a large disk
> cache, but nothing since switching to a database cache. I suspect my
> problem had something to do with the shutdown or inconsistencies after
> a forced shutdown.
>
> Al
>
> On 12/02/2008, Tim Cronin <tc...@interwoven.com> wrote:
> > We use jcs (1.3) in a web application, and over time we're seeing
> where
> >
> > two different keys (string based key) point to the same object
> >
> > say we have key "a" key "b" if I call JCS.getCacheElement("a")
> >
> > I get the element where the key = "b". I then call
> >
> > JCS.remove("b") then call JCS.get("b") I get null
> >
> > but if I call JCS.get("a") I get the object cached for "b"
> >
> > and subsequent calls to JCS.get("b") now return the object.
> >
> > only if call JCS.remove("a") will the problem be fixed.
> >
> > it also seems to "right" itself over time I believe if it
> > get dropped from the cache.
> >
> > I was able to see the key mismatch using the JCSAdmin.jsp
> > to interrogate the cache.
> >
> > I'm trying to track down exactly when this happens.
> >
> > ---------------------------------------------------------------------
> > 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
>
>
>
> ---------------------------------------------------------------------
> 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: cache corruption
Posted by Tim Cronin <tc...@interwoven.com>.
yes using indexed disk cache.
We can't afford to move to DB at this time...
Still trying to come up with at scenario to repro
I did notice some private members on the caches
IndexDiskCache.checkKeyDataConsistency(boolean)
LRUMemoryCache.verifyCache()
I can reflect into these if the error occurs
I don't see any defects In jira only the one
about hitting the cache files from different jvms.
The project seems quite is it still actively developed?
-----Original Message-----
From: Al Forbes [mailto:forbes.al@googlemail.com]
Sent: Tuesday, February 12, 2008 3:11 PM
To: JCS Users List
Subject: Re: cache corruption
Tim,
Are you using the disk cache? I had many problems with a large disk
cache, but nothing since switching to a database cache. I suspect my
problem had something to do with the shutdown or inconsistencies after
a forced shutdown.
Al
On 12/02/2008, Tim Cronin <tc...@interwoven.com> wrote:
> We use jcs (1.3) in a web application, and over time we're seeing
where
>
> two different keys (string based key) point to the same object
>
> say we have key "a" key "b" if I call JCS.getCacheElement("a")
>
> I get the element where the key = "b". I then call
>
> JCS.remove("b") then call JCS.get("b") I get null
>
> but if I call JCS.get("a") I get the object cached for "b"
>
> and subsequent calls to JCS.get("b") now return the object.
>
> only if call JCS.remove("a") will the problem be fixed.
>
> it also seems to "right" itself over time I believe if it
> get dropped from the cache.
>
> I was able to see the key mismatch using the JCSAdmin.jsp
> to interrogate the cache.
>
> I'm trying to track down exactly when this happens.
>
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org
Re: cache corruption
Posted by Al Forbes <fo...@googlemail.com>.
Tim,
Are you using the disk cache? I had many problems with a large disk
cache, but nothing since switching to a database cache. I suspect my
problem had something to do with the shutdown or inconsistencies after
a forced shutdown.
Al
On 12/02/2008, Tim Cronin <tc...@interwoven.com> wrote:
> We use jcs (1.3) in a web application, and over time we're seeing where
>
> two different keys (string based key) point to the same object
>
> say we have key "a" key "b" if I call JCS.getCacheElement("a")
>
> I get the element where the key = "b". I then call
>
> JCS.remove("b") then call JCS.get("b") I get null
>
> but if I call JCS.get("a") I get the object cached for "b"
>
> and subsequent calls to JCS.get("b") now return the object.
>
> only if call JCS.remove("a") will the problem be fixed.
>
> it also seems to "right" itself over time I believe if it
> get dropped from the cache.
>
> I was able to see the key mismatch using the JCSAdmin.jsp
> to interrogate the cache.
>
> I'm trying to track down exactly when this happens.
>
> ---------------------------------------------------------------------
> 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: cache corruption
Posted by Tim Cronin <tc...@interwoven.com>.
We are using indexed disk cache and the keys are all Strings.
we only call JCS.put, JCS.get, JCS.remove we never muck with the
CacheElement.
the way we saw the mix up was when we viewed the cache from
the JCSAdmin page and typing the keys in to the query field
the key wasn't showing up in the mem cache keys listing on
the details page.
this is happening at a customer site and I haven't been able to
reproduce the problem locally, but cache code is all
blacked boxed as far as the customer is concerned.
I've attached the ccf in case we've configured it improperly
(ive been digging through the docs to make sure I've set
thing correctly)
As soon as I can get more information I will post.
-----Original Message-----
From: Aaron Smuts [mailto:asmuts@yahoo.com]
Sent: Wednesday, February 13, 2008 2:09 PM
To: JCS Users List
Subject: Re: cache corruption
I've never seen anything like this happen. I need
more details. What auxiliaries are you using? Are
all the keys strings?
Please double check the code that is putting the items
in the cache. Perhaps the problem is there.
Aaron
--- Tim Cronin <tc...@interwoven.com> wrote:
> We use jcs (1.3) in a web application, and over time
> we're seeing where
>
> two different keys (string based key) point to the
> same object
>
> say we have key "a" key "b" if I call
> JCS.getCacheElement("a")
>
> I get the element where the key = "b". I then call
>
> JCS.remove("b") then call JCS.get("b") I get null
>
> but if I call JCS.get("a") I get the object cached
> for "b"
>
> and subsequent calls to JCS.get("b") now return the
> object.
>
> only if call JCS.remove("a") will the problem be
> fixed.
>
> it also seems to "right" itself over time I believe
> if it
> get dropped from the cache.
>
> I was able to see the key mismatch using the
> JCSAdmin.jsp
> to interrogate the cache.
>
> I'm trying to track down exactly when this happens.
>
>
---------------------------------------------------------------------
> 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: cache corruption
Posted by Aaron Smuts <as...@yahoo.com>.
I've never seen anything like this happen. I need
more details. What auxiliaries are you using? Are
all the keys strings?
Please double check the code that is putting the items
in the cache. Perhaps the problem is there.
Aaron
--- Tim Cronin <tc...@interwoven.com> wrote:
> We use jcs (1.3) in a web application, and over time
> we're seeing where
>
> two different keys (string based key) point to the
> same object
>
> say we have key "a" key "b" if I call
> JCS.getCacheElement("a")
>
> I get the element where the key = "b". I then call
>
> JCS.remove("b") then call JCS.get("b") I get null
>
> but if I call JCS.get("a") I get the object cached
> for "b"
>
> and subsequent calls to JCS.get("b") now return the
> object.
>
> only if call JCS.remove("a") will the problem be
> fixed.
>
> it also seems to "right" itself over time I believe
> if it
> get dropped from the cache.
>
> I was able to see the key mismatch using the
> JCSAdmin.jsp
> to interrogate the cache.
>
> I'm trying to track down exactly when this happens.
>
>
---------------------------------------------------------------------
> 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
cache corruption
Posted by Tim Cronin <tc...@interwoven.com>.
We use jcs (1.3) in a web application, and over time we're seeing where
two different keys (string based key) point to the same object
say we have key "a" key "b" if I call JCS.getCacheElement("a")
I get the element where the key = "b". I then call
JCS.remove("b") then call JCS.get("b") I get null
but if I call JCS.get("a") I get the object cached for "b"
and subsequent calls to JCS.get("b") now return the object.
only if call JCS.remove("a") will the problem be fixed.
it also seems to "right" itself over time I believe if it
get dropped from the cache.
I was able to see the key mismatch using the JCSAdmin.jsp
to interrogate the cache.
I'm trying to track down exactly when this happens.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org
RE: Dump Cache Entries in Memory to Index Disk
Posted by Aaron Smuts <as...@yahoo.com>.
Take a look at the context listener. I think that
you'll be able to come up with a solution.
http://jakarta.apache.org/jcs/xref/org/apache/jcs/utils/servlet/JCSServletContextListener.html
Aaron
--- dadade <de...@lmco.com> wrote:
>
> How do I call the shutdown method on the composite
> cache manager? What api
> set do I used?
>
> If I am using a stateful session bean to wrap around
> the JCS, when the bean
> becomes passivate, I want to dump all the cach
> entries in memory to disk.
> Do I call the shutdown method in the passivate
> method? Is there a "start"
> method in the activate method?
>
> Thanks
>
>
> Smuts, Aaron wrote:
> >
> > This happens on normal shutdown. Call the
> shutdown method on the
> > composite cache manager. You can also register a
> context listener in a
> > web app to do this for you.
> >
> >
> >
> >> -----Original Message-----
> >> From: dadade [mailto:deirdre.y.kong@lmco.com]
> >> Sent: Thursday, June 21, 2007 2:23 PM
> >> To: jcs-users@jakarta.apache.org
> >> Subject: Re: Dump Cache Entries in Memory to
> Index Disk
> >>
> >>
> >> I tried using the freeMemoryElements method but
> it is not working the
> > way
> >> I
> >> expected.
> >>
> >> Let's say I put 10 items in Memory Cache. Then I
> called
> >> freeMemoryElements
> >> and pass in 10 as the number to free. Then I
> shut down my
> > application.
> >> Next time, when I run my application to get the
> 10 items from the disk
> >> cache, only the last item is being retrieved
> correctly. All others'
> >> return
> >> values are null.
> >>
> >> Am I doing something wrong?
> >>
> >>
> >>
> >>
> >>
> >> dadade wrote:
> >> >
> >> > Hello,
> >> >
> >> > Is there a way (API) to spooled all the cache
> entries in LRU Memory
> > to
> >> > Index Disk?
> >> > Your help is appreciate.
> >> >
> >> > Thanks,
> >> >
> >>
> >> --
> >> View this message in context:
> > http://www.nabble.com/Dump-Cache-Entries-in-
> >> Memory-to-Index-Disk-tf3960435.html#a11238770
> >> Sent from the JCS - Users mailing list archive at
> Nabble.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 this message in context:
>
http://www.nabble.com/Dump-Cache-Entries-in-Memory-to-Index-Disk-tf3960435.html#a11242670
> Sent from the JCS - Users mailing list archive at
> Nabble.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: Dump Cache Entries in Memory to Index Disk
Posted by dadade <de...@lmco.com>.
How do I call the shutdown method on the composite cache manager? What api
set do I used?
If I am using a stateful session bean to wrap around the JCS, when the bean
becomes passivate, I want to dump all the cach entries in memory to disk.
Do I call the shutdown method in the passivate method? Is there a "start"
method in the activate method?
Thanks
Smuts, Aaron wrote:
>
> This happens on normal shutdown. Call the shutdown method on the
> composite cache manager. You can also register a context listener in a
> web app to do this for you.
>
>
>
>> -----Original Message-----
>> From: dadade [mailto:deirdre.y.kong@lmco.com]
>> Sent: Thursday, June 21, 2007 2:23 PM
>> To: jcs-users@jakarta.apache.org
>> Subject: Re: Dump Cache Entries in Memory to Index Disk
>>
>>
>> I tried using the freeMemoryElements method but it is not working the
> way
>> I
>> expected.
>>
>> Let's say I put 10 items in Memory Cache. Then I called
>> freeMemoryElements
>> and pass in 10 as the number to free. Then I shut down my
> application.
>> Next time, when I run my application to get the 10 items from the disk
>> cache, only the last item is being retrieved correctly. All others'
>> return
>> values are null.
>>
>> Am I doing something wrong?
>>
>>
>>
>>
>>
>> dadade wrote:
>> >
>> > Hello,
>> >
>> > Is there a way (API) to spooled all the cache entries in LRU Memory
> to
>> > Index Disk?
>> > Your help is appreciate.
>> >
>> > Thanks,
>> >
>>
>> --
>> View this message in context:
> http://www.nabble.com/Dump-Cache-Entries-in-
>> Memory-to-Index-Disk-tf3960435.html#a11238770
>> Sent from the JCS - Users mailing list archive at Nabble.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 this message in context: http://www.nabble.com/Dump-Cache-Entries-in-Memory-to-Index-Disk-tf3960435.html#a11242670
Sent from the JCS - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org
RE: Dump Cache Entries in Memory to Index Disk
Posted by "Smuts, Aaron" <Aa...@travelocity.com>.
This happens on normal shutdown. Call the shutdown method on the
composite cache manager. You can also register a context listener in a
web app to do this for you.
> -----Original Message-----
> From: dadade [mailto:deirdre.y.kong@lmco.com]
> Sent: Thursday, June 21, 2007 2:23 PM
> To: jcs-users@jakarta.apache.org
> Subject: Re: Dump Cache Entries in Memory to Index Disk
>
>
> I tried using the freeMemoryElements method but it is not working the
way
> I
> expected.
>
> Let's say I put 10 items in Memory Cache. Then I called
> freeMemoryElements
> and pass in 10 as the number to free. Then I shut down my
application.
> Next time, when I run my application to get the 10 items from the disk
> cache, only the last item is being retrieved correctly. All others'
> return
> values are null.
>
> Am I doing something wrong?
>
>
>
>
>
> dadade wrote:
> >
> > Hello,
> >
> > Is there a way (API) to spooled all the cache entries in LRU Memory
to
> > Index Disk?
> > Your help is appreciate.
> >
> > Thanks,
> >
>
> --
> View this message in context:
http://www.nabble.com/Dump-Cache-Entries-in-
> Memory-to-Index-Disk-tf3960435.html#a11238770
> Sent from the JCS - Users mailing list archive at Nabble.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: Dump Cache Entries in Memory to Index Disk
Posted by dadade <de...@lmco.com>.
I tried using the freeMemoryElements method but it is not working the way I
expected.
Let's say I put 10 items in Memory Cache. Then I called freeMemoryElements
and pass in 10 as the number to free. Then I shut down my application.
Next time, when I run my application to get the 10 items from the disk
cache, only the last item is being retrieved correctly. All others' return
values are null.
Am I doing something wrong?
dadade wrote:
>
> Hello,
>
> Is there a way (API) to spooled all the cache entries in LRU Memory to
> Index Disk?
> Your help is appreciate.
>
> Thanks,
>
--
View this message in context: http://www.nabble.com/Dump-Cache-Entries-in-Memory-to-Index-Disk-tf3960435.html#a11238770
Sent from the JCS - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
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 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
JCS as a Hibernate cache provider
Posted by Niall Gallagher <ni...@switchfire.com>.
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: Dump Cache Entries in Memory to Index Disk
Posted by dadade <de...@lmco.com>.
Thanks for your help. I have a better understanding.
Aaron Smuts wrote:
>
> Purgatory is a queue where items go on their way to
> disk after they leave memory.
>
> (This statement is going to look odd when it shows up
> in a Google results page out of context!)
>
> While in purgatory, items can still be accessed.
> Purgatory is basically a doubly-linked list with a
> size limit, fronted by a map. There is no other way
> to get to disk except through purgatory, regardless if
> the cache is shutting down or just swapping the data.
>
>
> The Indexed Disk Cache registers a shutdown observer.
> It will try to move all items from memory to disk on
> shutdown, but there is seldom time. It is far better
> to call shutdown properly. During an orderly
> shutdown, the cache will give itself up to a minute
> to write all items to disk. (I've never seen it take
> this long and the time limit is configurable.)
>
> Aaron Smuts
>
>
>
> --- dadade <de...@lmco.com> wrote:
>
>>
>> Thank you for your help.
>>
>> Another question is: What does MaxPurgatorySize
>> mean? Does it mean that
>> when shutdown occurs, all the items in the purgatory
>> area are written to
>> disk? If we don't call shutdown or
>> freeMemoryElements, the items in the
>> purgatory area won't go to disk? I read the Indexed
>> Disk Auxiliary Cache
>> page online, but would like further explanation.
>> Thank you again for your
>> help.
>>
>>
>>
>> dadade wrote:
>> >
>> > Hello,
>> >
>> > Is there a way (API) to spooled all the cache
>> entries in LRU Memory to
>> > Index Disk?
>> > Your help is appreciate.
>> >
>> > Thanks,
>> >
>>
>> --
>> View this message in context:
>>
> http://www.nabble.com/Dump-Cache-Entries-in-Memory-to-Index-Disk-tf3960435.html#a11256353
>> Sent from the JCS - Users mailing list archive at
>> Nabble.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 this message in context: http://www.nabble.com/Dump-Cache-Entries-in-Memory-to-Index-Disk-tf3960435.html#a11272768
Sent from the JCS - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org
Re: Dump Cache Entries in Memory to Index Disk
Posted by Aaron Smuts <as...@yahoo.com>.
Purgatory is a queue where items go on their way to
disk after they leave memory.
(This statement is going to look odd when it shows up
in a Google results page out of context!)
While in purgatory, items can still be accessed.
Purgatory is basically a doubly-linked list with a
size limit, fronted by a map. There is no other way
to get to disk except through purgatory, regardless if
the cache is shutting down or just swapping the data.
The Indexed Disk Cache registers a shutdown observer.
It will try to move all items from memory to disk on
shutdown, but there is seldom time. It is far better
to call shutdown properly. During an orderly
shutdown, the cache will give itself up to a minute
to write all items to disk. (I've never seen it take
this long and the time limit is configurable.)
Aaron Smuts
--- dadade <de...@lmco.com> wrote:
>
> Thank you for your help.
>
> Another question is: What does MaxPurgatorySize
> mean? Does it mean that
> when shutdown occurs, all the items in the purgatory
> area are written to
> disk? If we don't call shutdown or
> freeMemoryElements, the items in the
> purgatory area won't go to disk? I read the Indexed
> Disk Auxiliary Cache
> page online, but would like further explanation.
> Thank you again for your
> help.
>
>
>
> dadade wrote:
> >
> > Hello,
> >
> > Is there a way (API) to spooled all the cache
> entries in LRU Memory to
> > Index Disk?
> > Your help is appreciate.
> >
> > Thanks,
> >
>
> --
> View this message in context:
>
http://www.nabble.com/Dump-Cache-Entries-in-Memory-to-Index-Disk-tf3960435.html#a11256353
> Sent from the JCS - Users mailing list archive at
> Nabble.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: Dump Cache Entries in Memory to Index Disk
Posted by dadade <de...@lmco.com>.
Thank you for your help.
Another question is: What does MaxPurgatorySize mean? Does it mean that
when shutdown occurs, all the items in the purgatory area are written to
disk? If we don't call shutdown or freeMemoryElements, the items in the
purgatory area won't go to disk? I read the Indexed Disk Auxiliary Cache
page online, but would like further explanation. Thank you again for your
help.
dadade wrote:
>
> Hello,
>
> Is there a way (API) to spooled all the cache entries in LRU Memory to
> Index Disk?
> Your help is appreciate.
>
> Thanks,
>
--
View this message in context: http://www.nabble.com/Dump-Cache-Entries-in-Memory-to-Index-Disk-tf3960435.html#a11256353
Sent from the JCS - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org