Just a question, is the 1.4 Jackrabbit mandatory or can I replace by a dependency to 1.3 ?
Frédéric Esnault - Ingénieur R&D -----Message d'origine----- De : Thomas Mueller [mailto:[EMAIL PROTECTED] Envoyé : mercredi 20 juin 2007 11:56 À : [email protected] Objet : Re: atomic vs group node creation/storage Hi again, I tested it again with your code, and still couldn't find a problem. (There are probably small differences, for example I didn't use any node types, and I implemented my own createRandomData method). Could you verify you deleted the tables in the database between the test runs? If this doesn't help, could you run your code with the 'jcrlog' tool? It is available here: http://svn.apache.org/repos/asf/jackrabbit/trunk/contrib/jcrlog. I would help you use the tool (I wrote it). The tool logs all JCR operations to a file. In your test application, all child nodes have the same name (same name siblings). As Jukka pointed out, this is problematic for Jackrabbit. If you think about it, it will be problematic for the developer and user as well: if he will ever use a repository browser to check the data, he will see 50'000 child nodes with the same name. I think it should be avoided: I suggest to give each node a different name (an easy solution is to add a number, or a unique property). Another problem is for one single node to have lots of (many thousand) child nodes. This is not handled nicely in Jackrabbit, as well as in repository browsers. I suggest to use a deeper hierarchy: root +- contractors +- contractors1-999 +- contractor1 +- contractor2 +- contractors1000-1999 +- contractor1000 +- contractor1001 I do hope this problem will be solved in Jackrabbit and repository browsers, but as far as I understand using deeper hierarchies is 'best practice' at the moment. Thomas P.S. I could send you my test application if you want On 6/20/07, Thomas Mueller <[EMAIL PROTECTED]> wrote: > Hi, > > I am trying to reproduce the problem (with 1000 child nodes), but so > far I couldn't find a problem. This could have two reasons: > > A) Are you sure you cleaned the repository between tests? > B) The method initializeContractor. > Could you please send your code for initializeContractor? > I used: > > static void initializeContractor(Session session, Node contractor) > throws Exception { > contractor.setProperty("name", "Hello"); > } > > After testOneByOne I have: > SELECT COUNT(*) FROM default_binval: 0 > SELECT COUNT(*) FROM default_node: 1003 > SELECT COUNT(*) FROM default_prop: 2003 > SELECT COUNT(*) FROM default_refs: 0 > SELECT COUNT(*) FROM version_binval: 0 > SELECT COUNT(*) FROM version_node: 1 > SELECT COUNT(*) FROM version_prop: 1 > SELECT COUNT(*) FROM version_refs: 0 > > After testBatch I have: > SELECT COUNT(*) FROM default_binval: 0 > SELECT COUNT(*) FROM default_node: 1003 > SELECT COUNT(*) FROM default_prop: 2003 > SELECT COUNT(*) FROM default_refs: 0 > SELECT COUNT(*) FROM version_binval: 0 > SELECT COUNT(*) FROM version_node: 1 > SELECT COUNT(*) FROM version_prop: 1 > SELECT COUNT(*) FROM version_refs: 0 > > So, no difference. > > Thanks, > Thomas > > > > On 6/20/07, Jukka Zitting <[EMAIL PROTECTED]> wrote: > > Hi, > > > > On 6/20/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > > This seems more related to how the MySQL persistence manager handles > > > constant updates of a shared parent nodes with more and more child nodes. > > > Also your use of same name sibblings might be an issue, actually. > > > > This sounds like it could be a problem in how same name siblings are > > handled in NodeState. If this is the case and someone can further > > qualify the issue and fix it in a short timeframe, I would very much > > like to have the fix included in 1.3.1. > > > > BR, > > > > Jukka Zitting > > >
