-
1. Re: segmented persistence
belaban Sep 18, 2005 2:19 PM (in response to motormind)This is not possible with the current cache. However, when we introduce the Clustered CacheLoader, it might be an option to have a local copy. Or, we could use multiple CacheLoaders with CacheLoader Chaining. Both of these 2 feature will be introduced in 1.3
-
2. Re: segmented persistence
motormind Sep 19, 2005 8:04 AM (in response to motormind)"bela@jboss.com" wrote:
This is not possible with the current cache. However, when we introduce the Clustered CacheLoader, it might be an option to have a local copy. Or, we could use multiple CacheLoaders with CacheLoader Chaining. Both of these 2 feature will be introduced in 1.3
Right now I am trying to build a cacheloader that behaves differently, according to the configuration file. But when I different cacheloaders, they are always set for the whole tree? That is a major pain. -
3. Re: segmented persistence
belaban Sep 19, 2005 8:15 AM (in response to motormind)Yes, CacheLoaders are set for the entire tree. We are looking into moving to a regions-based JBossCache later on.
-
4. Re: segmented persistence
motormind Sep 19, 2005 9:01 AM (in response to motormind)"bela@jboss.com" wrote:
Yes, CacheLoaders are set for the entire tree. We are looking into moving to a regions-based JBossCache later on.
So, is it then possible to make one cacheloader, that behaves differently while running on several processes? E.g. I want that cacheloader to store state on the server processes, but to skip it while running on the clients. -
5. Re: segmented persistence
belaban Sep 19, 2005 10:10 AM (in response to motormind)Sure, depends on what you code. For example, a CacheLoader impl can have its own configuration, you could have 2 sets of configurations. Or read a system property in your implementation
-
6. Re: segmented persistence
motormind Sep 19, 2005 10:45 AM (in response to motormind)"bela@jboss.com" wrote:
Sure, depends on what you code. For example, a CacheLoader impl can have its own configuration, you could have 2 sets of configurations. Or read a system property in your implementation
Actually, I am using seperate configuration files now. Alas, I found out that you can't return null values ina CacheLoader implementation, or rhte system will balk with nullpointerexceptions. -
7. Re: segmented persistence
belaban Sep 19, 2005 11:01 AM (in response to motormind)You should be able to. What case is this ?
Do you implement the exists() ? Then I shouldn't even call you.
Note that some work on CacheLoaders in general is planned for the next release (1.3) -
8. Re: segmented persistence
motormind Sep 20, 2005 3:48 AM (in response to motormind)"bela@jboss.com" wrote:
You should be able to. What case is this ?
Do you implement the exists() ? Then I shouldn't even call you.
I get it with loadEntireState when I try to use it as a real CacheLoader. Eseentially I subclasses FileCacheLoader and then simply call the super implementation or - when it's not a server - I return an ampty byte array.
Note that some work on CacheLoaders in general is planned for the next release (1.3)
That's nice, but I need it right now. I am surprised it is not a feature already. -
9. Re: segmented persistence
belaban Sep 20, 2005 4:20 AM (in response to motormind)The "I need it right now" sounds familiar :-)
Maybe there is a mismatch in your trying to use a peer-to-peer system for a client-server application. I'll think of this use case when I get to 1.3 -
10. Re: segmented persistence
motormind Sep 20, 2005 5:26 AM (in response to motormind)"bela@jboss.com" wrote:
The "I need it right now" sounds familiar :-)
Maybe there is a mismatch in your trying to use a peer-to-peer system for a client-server application. I'll think of this use case when I get to 1.3
Well, it just seemed like a reasonable idea to let the GUI part view the same cache that the server is manipulating. -
11. Re: segmented persistence
belaban Sep 20, 2005 6:54 AM (in response to motormind)Okay, how about not using a CacheLoader at all for clients ?
Or using a ClusteredCacheLoader once 1.3 comes around ? -
12. Re: segmented persistence
motormind Sep 22, 2005 4:01 AM (in response to motormind)"bela@jboss.com" wrote:
Okay, how about not using a CacheLoader at all for clients ?
Or using a ClusteredCacheLoader once 1.3 comes around ?
I tried making seperate xml-configurations for the clients and the servers... the ones for the clients did not have any data regarding persistence. The servers should each have their own local copy of the cache. It seemed to me though that the persistence-configuration got overwritten once I started a client, since there can be only one cacheloader per TreeCache. Is that possible?
In any case, the other servers simply refused to load the cache and persit it themselves.. -
13. Re: segmented persistence
belaban Sep 22, 2005 4:27 AM (in response to motormind)Okay, all members have a copy of their state. But what I meant was that only *clients* would have *no* CacheLoader configured, so their data would not be persisted
-
14. Re: segmented persistence
motormind Sep 26, 2005 3:48 AM (in response to motormind)"bela@jboss.com" wrote:
Okay, all members have a copy of their state. But what I meant was that only *clients* would have *no* CacheLoader configured, so their data would not be persisted
Well, I set up the clients with no cacheloader-implementation. The result is that when the clients start first, the cache of the servers doesn't get propagated to them. When the servers start first, the goed does get propagated, although I get this error on the client-side:
jgroups-ERROR-TreeCache$MessageListenerAdaptor: cache loader is null, cannot set persistent state