jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frédéric Esnault <f...@legisway.com>
Subject RE: atomic vs group node creation/storage
Date Thu, 21 Jun 2007 13:42:02 GMT
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

Frédéric Esnault

-----Message d'origine-----
De : Thomas Mueller [mailto:thomas.tom.mueller@gmail.com] 
Envoyé : jeudi 21 juin 2007 11:25
À : dev@jackrabbit.apache.org
Objet : Re: atomic vs group node creation/storage


> 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,


> 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


Attachment: testSingleGroup.zip (I hope this works)

View raw message