-
1. Re: problem when using new Fqn with Integer
genman Feb 8, 2007 1:28 PM (in response to emailmsgbox)The file cache loader does not support integers in FQN.
-
2. Re: problem when using new Fqn with Integer
emailmsgbox Feb 8, 2007 5:49 PM (in response to emailmsgbox)thanks for your reply ,
but if I understand you correctlly ,It more a bug the a feature issue .
Since if I choose persistancy in my configuration ,I should not need to change the code
from the documentation
String n1 = "/300/322649";
Fqn n2 = new Fqn(new Object{new Integer(300), new Integer(322649)});
In this example, we want to access a node that has information for employee with id=322649 in department with id=300. The string version needs two map lookups on Strings, whereas the Fqn version needs two map lookups on Integers. In a large hashtable, the hashCode() method for String may have collisions, leading to actual string comparisons. Also, clients of the cache may already have identifiers for their objects in Object form, and don't want to transform between Object and Strings, preventing unnecessary copying. -
3. Re: problem when using new Fqn with Integer
manik Feb 9, 2007 6:06 AM (in response to emailmsgbox)See http://labs.jboss.com/file-access/default/members/jbosscache/freezone/docs/1.4.1/api/org/jboss/cache/loader/FileCacheLoader.html#getChildrenNames(org.jboss.cache.Fqn)
I agree that having to restrict your Fqn components based on how you persist your data is a bit poor, but this is a restriction necessary because of how certain persistence mechanisms work.
See this thread, please comment there. -
4. Re: problem when using new Fqn with Integer
emailmsgbox Feb 11, 2007 5:04 AM (in response to emailmsgbox)its is not a "bit poor" , inconsistent cache behavior is a big bug.
you can start by removing the use of Integer object from the document.
this pitfall is confusing at best
also , what about performance?
When I put my user hat(not design hat) I think IMHO that the FQN API should be String only until this design issue is resolved -
5. Re: problem when using new Fqn with Integer
manik Feb 22, 2007 11:36 AM (in response to emailmsgbox)
When I put my user hat(not design hat) I think IMHO that the FQN API should be String only until this design issue is resolved
I agree, there is a thread about whether this should be the case. See http://jboss.org/index.html?module=bb&op=viewtopic&t=101146
its is not a "bit poor" , inconsistent cache behavior is a big bug.
Not really; this restriction exists in a number of subsystems, although I agree that it should be better documented. It is *intended* that Fqns are restricted as such.