Hi guys! Can anyone, please, comment at least on these points from below mail:
2) Is it true that "journaling" has locking issues because of only one instance of "journal" accessed by repository? As far as I see it is the case as when multiple save operations happen then they will effectively become sequential because of single ReentrantWriterPreferenceReadWriteLock held by a single instance of journal accessed by different threads despite of the JCR nodes they are updating. 4) What is the logical/practical limit on the number of cluster nodes participating in "journaling"? As far as I see because of the locking mechanism described above the more cluster nodes we add the worse it will behave when there is a certain amount of save operations happen on each cluster node. 5) Are there any ideas floating in JR community on how to implement "less-locking" journal? Am I totally wrong on all these points? Is there any practical/production experience someone can share? Any help is really appreciated. Best regards, Andrey ________________________________ From: Andrey Adamovich <[email protected]> To: [email protected] Sent: Mon, 14 December, 2009 14:14:00 Subject: Journalling (does it work?) Hello JR users and developers! Recently we have faced a problem with journalling that seems to resemble the one reproduced in JCR-1846 (https://issues.apache.org/jira/browse/JCR-1846). But that defect is closed and said to be fixed since 1.5.2, but we are using 1.5.5. And in relation to that I have several questions: 1) Is "journaling" recommended for production use? 2) Is it true that "journaling" has locking issues because of only one instance of "journal" accessed by repository? 3) Is it possible to overcome the limitation we have faced and described in JCR-1846 and make journal do its job? 4) What is the logical/practical limit on the number of cluster nodes participating in "journaling"? 5) How smart or risky is it to implement our own "journaling"? Best regards, Andrey
