Re: Errors with new cluster feature

[Dominique Pfister <do...@day.com>]

Hi Miguel,

Yes, I'd be very interested in your PostgreSQL specific DDL to include
in the upcoming 1.3 release. Please note, that there has been a slight
schema change: I would appreciate if you could synchronize with
default.ddl in trunk.

Kind regards
Dominique

On 2/21/07, Miguel Ángel Jiménez <mi...@gmail.com> wrote:
> Hi,
>
> I'm testing the new DatabaseJournal with a PostgreSQL. Since there was no
> ddl for this database I had to generate one and thought you could upload it
> to subversion.
>
> Regards,
>
>
>  On 21/02/07, Dominique Pfister <do...@day.com> wrote:
> > Hi Miguel
> >
> > On 2/20/07, Miguel Ángel Jiménez <mi...@gmail.com> wrote:
> > > Thanks again for the response. I have another issue about FileJournal.
> In
> > > our test environment, we have several instances doing concurrent
> > > modifications to the repository and have been able to trace what I see
> as a
> > > possible bug in log file rotation. It seems that the renaming of old
> files
> > > is not working as expected. For example, journal.log.1 does not get
> renamed
> > > to journal.log.2 when rotating the current log file. I think the problem
> is
> > > class FileJournal method switchLogs:
> > >
> > > String newName = name.substring(0, sep + 1) + String.valueOf (version +
> 1);
> > > file.renameTo(new File(newName));
> > >
> > > The new name does not preserve the original path of the renamed file.
> > > Wouldn't be better to do...
> > >
> > > String newName = name.substring (0, sep + 1) + String.valueOf(version +
> 1);
> > > file.renameTo(new File(root, newName));
> > >
> > > ... or something similar? Makes it sense to you?
> >
> > Absolutely! I fixed this only yesterday while fixing some other issues
> > (JCR-749,JCR-756,JCR-757) as well. Great bug tracking work!
> >
> > Kind regards
> > Dominique
> >
> > >
> > > Thanks for the advance on the new DatabaseJournal. I'm looking forward
> to
> > > this solution as it suits well with our current deployment model.
> > >
> > > Kind regards,
> > >
> > >
> > >
> > >
> > >
> > > On 20/02/07, Dominique Pfister <do...@day.com> wrote:
> > > >
> > > > Hi Miguel,
> > > >
> > > > On 2/20/07, Miguel Ángel Jiménez <mi...@gmail.com> wrote:
> > > > > The call to globalRevision.set (that implies a lock) is done after
> the
> > > > call
> > > > > to recordLog.append() so I think the write is not protected. I'm
> rather
> > > > new
> > > > > to JCR and jackrabbit so maybe I'm missing something but the cluster
> > > > feature
> > > > > is very important for our product. I'm going to develop some classes
> to
> > > > test
> > > > > basic cluster operation and hope it helps to further improve in this
> > > > area.
> > > >
> > > > Well, the method FileJournal.prepare() exclusively locks the global
> > > > revision:
> > > >
> > > >   public void prepare() throws JournalException {
> > > >       globalRevision.lock (false);
> > > >       ...
> > > >   }
> > > >
> > > > and this method is called before the actual FileJournal.commit().
> > > >
> > > > In Jackrabbit 1.2.2, a DatabaseJournal has been added, that stores its
> > > > record in a shared database. If the persistence managers you're using
> > > > already share a standalone database, this might be an option.
> > > >
> > > > Kind regards
> > > > Dominique
> > > >
> > >
> > >
> > >
> > > --
> > > Miguel.
> > >
> >
>
>
>
> --
> Miguel.