hi shaun, On 8/16/07, sbarriba <[EMAIL PROTECTED]> wrote: > Hi all, > > We upgraded to JackRabbit 1.3.1 a few days ago. > > We have since seen a couple of occasions where we've been able to get the > repository in an indeterminate state. The following output shows the state > of a node which has an ordered child node property called acme:components > e.g. > > > > [miq:FooBar] > nt:base > > orderable > > + acme:components (acme:Component) multiple COPY > > > > We have an instance of FooBar where acme:components[5] has disappeared?? > > e.g. > > > > name type node new modified > > ------------------------------ --------------- --------- --------- --------- > > acme:components acme:Section true false false > > acme:components[2] acme:Text true false false > > acme:components[3] acme:Text true false false > > acme:components[4] acme:Text true false false > > acme:components[6] acme:Section true false false > > acme:components[7] acme:Section true false false > > jcr:created Date false false false > > jcr:primaryType Name false false false > > jcr:uuid String false false false > > > > I presume this could happen if the deletion of the child node succeeded by > the saving of the parent FooBar node failed for some reason?
that should be possible since the changelog of a save operation is stored atomically. if an error occurs during processing of the change log all previous changes are rolled back. > > > > Surely this is a state that should never happen? absolutely, and the problem you're describing is very alarming indeed! did you notice anything peculiar about the corrupt nodes? is there a chance to reconstruct the steps that lead to this state? furthermore, could you please share some details about your config/deployment? the only possible explanation i can currently come up with is that there are multiple jackrabbit instances accessing the same database... cheers stefan > > > > Regards, > > Shaun > > > >
