Hi Stefan, First thanks for your answer. In fact I just found in a mailing list a message from you about this, explaining this blob size limit problem. And your answer here answers my other question : why is my webapp didn't have this problem when creating a node with 12 000 child nodes, and why this external tool does only creating 2 500 child nodes.
In fact my webapp is configured in maven, with jackrabbit 1.3 as a dependency. For this tool, I quickly copied jars of Jackrabbit 1.2.3. Shame on me ;-) Frédéric Esnault -----Message d'origine----- De : Stefan Guggisberg [mailto:[EMAIL PROTECTED] Envoyé : jeudi 21 juin 2007 15:54 À : [email protected] Objet : Re: atomic vs group node creation/storage On 6/21/07, Frédéric Esnault <[EMAIL PROTECTED]> wrote: > Now I have a strange problem with the test tool. I tried to launch creation > on 2500 nodes, and got this : > Exception in thread "main" javax.jcr.RepositoryException: /: unable to update > it > em.: failed to write node state: 409d58ab-bd92-410c-8096-1fca52b8ef63: failed > to > write node state: 409d58ab-bd92-410c-8096-1fca52b8ef63 > at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1212) > at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:823) > at TestSingleGroup.testOneByOne(TestSingleGroup.java:109) > > Caused by: com.mysql.jdbc.MysqlDataTruncation: Data truncation: Data too long > fo > r column 'NODE_DATA' at row 1 seems like you hit the size limit of the 'blob' data type. for more information see https://issues.apache.org/jira/browse/JCR-760. please note that this issue should have been fixed in the 1.3 release. what version are you using? cheers stefan > > > Frédéric Esnault > > -----Message d'origine----- > De: Thomas Mueller [mailto:[EMAIL PROTECTED] > Envoyé: jeudi 21 juin 2007 11:25 > À: [email protected] > Objet: Re: atomic vs group node creation/storage > > Hi, > > > The number of rows was increasing also very fast. > > When my default_node table reached 22 GB, it was holding 35 million rows. > > Is the problem now, that it is reproducible on your machine, but not > on my machine? Could you run my test case on your machine? It is > simpler and doesn't use node types. If you can't reproduce the problem > with my test on your machine, but can reproduce it with your test > case, could you send your complete test code (there are still some > pieces missing, for example initializeContractor)? > > > The problem here is that if you use predicate on the node with plenty of > > instances (say a contract), the search works fine, > > OK > > > the problem is if the search has to look at all the instances of this type > > of node. > > I'm not sure if I understand the problem... You would search all nodes > of the same type without any condition ("SELECT * FROM x:y")? Why > would you do a search like this, and how would using same name > siblings solve the problem? > > > We actually plan a 100K nodes repository, with an extreme limit to 250K, > > which could possibly mean something like a maximum of 25K to 30K child > > nodes, > > Somebody else already said, many child nodes is only a problem for > writing. And for manually browsing the repository, if you want to do > that. > > Thomas > > Attachment: testSingleGroup.zip (I hope this works) >
