Re: [jr3] clustering

Hi, I don't see a need why the parent node needs to be updated when a child node is added, removed or updated. However, getting a consistent journal across cluster nodes seems more difficult here as you said. One option might be to persist the journal within or near the node data itself. I

[jira] [Created] (JCR-3247) SQL2 ISDESCENDANTNODE BooleanQuery#TooManyClauses returns

SQL2 ISDESCENDANTNODE BooleanQuery#TooManyClauses returns - Key: JCR-3247 URL: https://issues.apache.org/jira/browse/JCR-3247 Project: Jackrabbit Content Repository Issue Type: Bug

[jira] [Resolved] (JCR-3247) SQL2 ISDESCENDANTNODE BooleanQuery#TooManyClauses returns

[ https://issues.apache.org/jira/browse/JCR-3247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Parvulescu resolved JCR-3247. -- Resolution: Fixed Fix Version/s: 2.5 fixed in revision 1296202 SQL2

[jira] [Resolved] (JCR-3248) TimeoutHandler visitor should be extracted into a dedicated class

[ https://issues.apache.org/jira/browse/JCR-3248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Parvulescu resolved JCR-3248. -- Resolution: Fixed Fix Version/s: 2.5 fixed in revision 1296214.

[jira] [Created] (JCR-3248) TimeoutHandler visitor should be extracted into a dedicated class

TimeoutHandler visitor should be extracted into a dedicated class - Key: JCR-3248 URL: https://issues.apache.org/jira/browse/JCR-3248 Project: Jackrabbit Content Repository

[jira] [Resolved] (JCR-3158) Deadlock in DBCP when accessing node

[ https://issues.apache.org/jira/browse/JCR-3158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Parvulescu resolved JCR-3158. -- Resolution: Fixed Fix Version/s: 2.5 this looks serious enough. I've ran all the tests

[jira] [Commented] (JCR-3158) Deadlock in DBCP when accessing node

[ https://issues.apache.org/jira/browse/JCR-3158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13220963#comment-13220963 ] Grégory Joseph commented on JCR-3158: - Any chance of a backport to the 2.4 branch ?

[jira] [Commented] (JCR-3243) RepositoryStatistics should be more flexible

[ https://issues.apache.org/jira/browse/JCR-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13220994#comment-13220994 ] Alex Parvulescu commented on JCR-3243: -- Good work Mete! There is still something I

[jira] [Commented] (JCR-3243) RepositoryStatistics should be more flexible

[ https://issues.apache.org/jira/browse/JCR-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221007#comment-13221007 ] Mete Atamel commented on JCR-3243: -- Thanks for the feedback. Regarding getType method, yes,

Re: [jr3] Tree model

On Thu, Mar 1, 2012 at 8:13 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, It looks my initial attempt at this didn't work too well, as my intention wasn't clear enough and the interface draft I included seemed to raise mostly concerns about technicalities (too many methods, etc.)

Re: [VOTE] Codename for the jr3 implementation effort (Was: [jr3] Codename)

[x] Oak Tough decision, the blackrabbit one was pretty cool too. alex On Fri, Mar 2, 2012 at 5:02 PM, Jukka Zitting jukka.zitt...@gmail.comwrote: Hi, On Fri, Mar 2, 2012 at 4:58 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Thus, please vote on which of these two codenames we should

Re: [VOTE] Codename for the jr3 implementation effort (Was: [jr3] Codename)

Thus, please vote on which of these two codenames we should use for the jr3 implementation effort: [x] Oak cheers stefan

[jira] [Commented] (JCR-3243) RepositoryStatistics should be more flexible

[ https://issues.apache.org/jira/browse/JCR-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221031#comment-13221031 ] Alex Parvulescu commented on JCR-3243: -- So, I'm not sure which one is worse: return

[jira] [Commented] (JCR-3186) Export size of Observation eventQueue to JMX

[ https://issues.apache.org/jira/browse/JCR-3186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221035#comment-13221035 ] Alex Parvulescu commented on JCR-3186: -- It is interesting that we already have the

Re: [jr3] Tree model

Hi, Thanks Jukka for the valuable analysis. See below for my preferences. 1) Properties and child nodes are all addressed using an unordered name-item mapping on the parent node. 2) Neither properties nor child nodes know their own name (or their parent). That information is kept only within

Re: [jr3] Tree model

On 2.3.12 16:17, Stefan Guggisberg wrote: * The data model specifies that a node contains an an array of (child) node objects and seems to imply that child nodes are always orderable. This is a major design constraint for the underlying storage model that doesn't seem necessary (a

Re: [VOTE] Codename for the jr3 implementation effort (Was: [jr3] Codename)

[ ] Blackrabbit [x] Oak The oak is a common symbol of strength and endurance ... - wikipedia regards, david

Re: [VOTE] Codename for the jr3 implementation effort (Was: [jr3] Codename)

On Mar 2, 2012, at 10:07 AM, David Nuescheler wrote: [ ] Blackrabbit [x] Oak The oak is a common symbol of strength and endurance ... - wikipedia Yeah, it's also one of the more commonly used codenames. Java itself was called Oak before its release. But that's okay as long as we don't