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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> Hi Miguel
>
> On 2/20/07, Miguel Ángel Jiménez <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi Miguel,
> > >
> > > On 2/20/07, Miguel Ángel Jiménez <[EMAIL PROTECTED]> 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.
