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?
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.
