[EMAIL PROTECTED] wrote :
| A cache is not a database. A database is, by definition, persistent
storage so such behaviour is nonsensical for a db. And this is why caches
delegate persistence to dbs - in JBC's case using a cache loader.
Umm, persistence is a relative term, valid within a
supi wrote :
|
| I disagree. When a cache stops, you should lose the ability to operate on
the data through the cache interface. I've never seen a database deleting
tables when you stop the db server/agent.
|
|
A cache is not a database. A database is, by definition, persistent
supi wrote :
| 1) API changes
| There's already a thread about this regarding listener notification.
|
That selfsame thread contains explanations as to why this was done, along with
links to other threads where this was publicly discussed beforehand.
supi wrote :
| 2) Behavior
Actually, the javadocs on stop() and destroy() are misleading - thanks for
bringing this up, I've fixed this in CVS now.
Please see http://lists.jboss.org/pipermail/jbosscache-dev/2007-May/001569.html
for the discussion thread that led to the decisions around when the cache is
emptied.
View
[EMAIL PROTECTED] wrote : [EMAIL PROTECTED] wrote : This problem has been
fixed, try the latest cvs HEAD checkout if you want to verify it works for you.
|
| Thank a lot, Jason! Works perfectly so far.
|
View the original post :
anonymous wrote : When a cache stops, you are meant to lose this in-memory
state.
I disagree. When a cache stops, you should lose the ability to operate on the
data through the cache interface. I've never seen a database deleting tables
when you stop the db server/agent. I would agree with you
Brian Stansberry in jbosscache-dev wrote :
| Basically, the state transfer semantics imply that the in-memory state
| is consistent with the cluster when start returns. Either its
| consistent because it's been transferred, or it's consistent because
| it's empty and waiting to be
[EMAIL PROTECTED] wrote : supi wrote :
| | 3) New bugs introduced
| | I admitt, I only ran a couple of our automated tests, but it didn't
look pretty. Pojo cache can't even handle the following anymore:
| |
|
| Thanks, I created an issue for this problem here:
|
supi wrote :
| 3) New bugs introduced
| I admitt, I only ran a couple of our automated tests, but it didn't look
pretty. Pojo cache can't even handle the following anymore:
|
Thanks, I created an issue for this problem here:
http://jira.jboss.com/jira/browse/JBCACHE-1150
-Jason
View
