Good stuff. No ideas yet about improving transfer format (at least from me). Thought of hand serializing fqns as strings but now fqns can have any object as path elements so that's out. During state transfer operation inevitable put and get from underlying cacheloader are much more expensive and I am not sure if it will make much difference in the end? > -----Original Message----- > From: Bela Ban > Sent: Thursday, August 31, 2006 5:47 PM > To: Vladimir Blagojevic > Cc: jbosscache-dev(a)lists.jboss.org > Subject: Re: [jbosscache-dev] Need for CacheLoader.storeState? > > Absolutely, I had that idea when I wrote the cache loader > interface, but never saw it through... +1 for sure, this > takes a lot of pain out of the implementations. > > Are you guys thinking about a more efficient transfer format, > or is NodeData still the awy to go ? > > Vladimir Blagojevic wrote: > >> Hi, >> >> After we resolve streaming format incompatible cacheloader >> implementations [1][2], and as we continue to follow newly agreed >> streaming state transfer format - we do not have to require >> cacheloader implementers to write their own implementations of >> storeEntireState and storeState ! >> >> CacheLoader.storeEntireState and CacheLoader.storeState are >> > always the > >> same. They read NodeData objects from stream and call put with >> underlying cacheloader. Put method does the cacheloader >> > specific stuff. > >> We can possibly keep storeEntireState and storeState in CacheLoader >> API but move default implementations to AbstractCacheLoader. Any >> suggestions or opinions? >> >> >> [1] http://jira.jboss.com/jira/browse/JBCACHE-748 >> [2] http://jira.jboss.com/jira/browse/JBCACHE-749 >> >> _______________________________________________ >> jbosscache-dev mailing list >> jbosscache-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosscache-dev >> >> >> > -- > Bela Ban > Lead JGroups / Manager JBoss Clustering Group JBoss - a > division of Red Hat > > > _______________________________________________ jbosscache-dev mailing list jbosscache-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosscache-dev

Bela Ban wrote: > Okay. We can actually say that FQNs can only have strings as > components, which is a requirement for some cache loaders anyway > (JDBC for instance) The JDBM cache loader I worked on allowed for FQNs composed of any object, including "null" of course. I believe a unit test checked if null was supported. I'm not sure allowing for any object is a useful feature for most or any customer, but it's the least astonishing for the user. I recall a forum thread that had one customer wondering why their data wasn't coming back because FQN components were converted to strings upon store. And then there's the question of how to appropriately store and restore null strings. I also wonder about FQNs with "/" or null characters in them, in a file system context they need to be escaped. When working with a text column, it might make sense to convert non- strings to a Java serialized, Base-64 string. Or, if the DB supports it, simply store FQNs serialized in a short byte array or blob. At the very least, throwing out an exception for non-strings during store makes a lot of sense. _______________________________________________ jbosscache-dev mailing list jbosscache-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosscache-dev