RE:JCRLog

[Frédéric Esnault <fe...@legisway.com>]

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:thomas.tom.mueller@gmail.com] 
Envoyé : mercredi 20 juin 2007 11:56
À : dev@jackrabbit.apache.org
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 <th...@gmail.com> 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 <ju...@gmail.com> wrote:
> > Hi,
> >
> > On 6/20/07, Felix Meschberger <Fe...@day.com> 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
> >
>

Re: JCRLog

[Thomas Mueller <th...@gmail.com>]

The JCRLog theoretically works on any JCR implementation, so both
Jackrabbit 1.3 and 1.4 work.

Thomas