Re: node locking when connection pool is used ?

Hi, Sorry for the late response. On 9/11/07, ruchi goel [EMAIL PROTECTED] wrote: In our design , instead of having one repository connection per user session , we would like to have a pool of repository connections which can be shared between the end user http sessions. As per JSR170

Re: release for Jackrabbit 1.4

Hi, On 9/11/07, ruchi goel [EMAIL PROTECTED] wrote: What is the expected time frame for release of Jackrabbit 1.4 ? I don't yet have any exact dates, but I'd expect at least a month or two before the release is ready. At least we still need to finalize the data store implementation and handle

[jira] Created: (JCR-1136) Timeout for locked nodes

Timeout for locked nodes Key: JCR-1136 URL: https://issues.apache.org/jira/browse/JCR-1136 Project: Jackrabbit Issue Type: New Feature Components: webdav Affects Versions: 1.3.1 Reporter:

RE: Synchronized methods in ItemManager

Hi, I should have explained my question in more detail. The Javadoc of the ItemManager states that there's one ItemManager per Session: it is created in the constructor of SessionImpl. Sessions are not thread-safe by specification. Because some methods in the ItemManager are synchronized, an

[jira] Created: (JCR-1137) test cases relying on Node.equals()

test cases relying on Node.equals() --- Key: JCR-1137 URL: https://issues.apache.org/jira/browse/JCR-1137 Project: Jackrabbit Issue Type: Bug Components: JCR TCK Reporter: Julian Reschke

Re: Synchronized methods in ItemManager

I should have explained my question in more detail. The Javadoc of the ItemManager states that there's one ItemManager per Session: it is created in the constructor of SessionImpl. Sessions are not thread-safe by specification. Because some methods in the ItemManager are synchronized, an

Re: [jira] Commented: (JCR-905) Clustering: race condition may cause duplicate entries in search index

Hi Andrea, yes, please do so. If you see that the problem is gone with the patch I will commit it. regards marcel Andrea K. wrote: Hi Marcel, I'm just trying your proposed patch on a cluster. If you want I can send you the resulting JR debug log and personal impressions. Thanks. Andrea -

Re: Synchronized methods in ItemManager

Hi, we have the feeling that the synchronization overhead begins to count on a multiprocessor (8 CPUs) platform. Do you have some test case where this can be verified? on a single session instance I personally prefer a more coarse grained synchronization I agree. In my view, an

[jira] Resolved: (JCR-1131) JCR2SPI NodeEntryImpl throws NPE during reorderNodes

[ https://issues.apache.org/jira/browse/JCR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved JCR-1131. --- Resolution: Fixed Fixed in revision: 576296 Thanks for reporting this issue. JCR2SPI

[jira] Updated: (JCR-1131) JCR2SPI NodeEntryImpl throws NPE during reorderNodes

[ https://issues.apache.org/jira/browse/JCR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated JCR-1131: -- Affects Version/s: (was: 1.4) JCR2SPI NodeEntryImpl throws NPE during reorderNodes

Re: Synchronized methods in ItemManager

Marcel Reutegger wrote: our official statement still is you may use multiple threads on a session that just read but a single thread on a session that writes. in - Could you please provide a pointer to that statement? - Also, we need to keep in mind that even if Jackrabbit allows that, JCR

[jira] Created: (JCR-1138) Data store garbage collection

Data store garbage collection - Key: JCR-1138 URL: https://issues.apache.org/jira/browse/JCR-1138 Project: Jackrabbit Issue Type: Improvement Components: core Reporter: Thomas Mueller

[jira] Commented: (JCR-1138) Data store garbage collection

[ https://issues.apache.org/jira/browse/JCR-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528000 ] Thomas Mueller commented on JCR-1138: - Revision 576314: added a test case and fixed a bug: The garbage collecter

Validation in QName class

Hi all, The QName class does not do any validation on the syntax of the local part. As a result, it is really easy to destroy your repository by registration of a nodetype with, for instance, a property with QName {http://myapp/a}local1:local2. The NodeTypeRegistry only validates the prefix part

Re: Validation in QName class

hi martijn, On 9/17/07, Martijn Hendriks [EMAIL PROTECTED] wrote: Hi all, The QName class does not do any validation on the syntax of the local part. As a result, it is really easy to destroy your repository by registration of a nodetype with, for instance, a property with QName

Re: Validation in QName class

On 9/17/07, Stefan Guggisberg [EMAIL PROTECTED] wrote: hi martijn, On 9/17/07, Martijn Hendriks [EMAIL PROTECTED] wrote: Hi all, The QName class does not do any validation on the syntax of the local part. As a result, it is really easy to destroy your repository by registration of a

RE: Validation in QName class

Hi Stefan, Performance is a good argument of course. For this particular problem, however, I think that some check inside Jackrabbit is needed because the whole repository may become unusable by one wrong QName. The NodeTypeRegistry.validateNodeTypeDef method could be used for that. What do you

Re: Validation in QName class

Hi, On 9/17/07, Martijn Hendriks [EMAIL PROTECTED] wrote: Performance is a good argument of course. For this particular problem, however, I think that some check inside Jackrabbit is needed because the whole repository may become unusable by one wrong QName. The

RE: Validation in QName class

Hi, On 9/17/07, Martijn Hendriks [EMAIL PROTECTED] wrote: Performance is a good argument of course. For this particular problem, however, I think that some check inside Jackrabbit is needed because the whole repository may become unusable by one wrong QName. The

RE: Synchronized methods in ItemManager

Hi, we have the feeling that the synchronization overhead begins to count on a multiprocessor (8 CPUs) platform. Do you have some test case where this can be verified? No, not yet but we're working on it. As soon as we have some results I'll get back on this. Best wishes, Martijn

Re: Validation in QName class

Hi, On 9/17/07, Martijn Hendriks [EMAIL PROTECTED] wrote: However, the officially supported node type registration methods are the ones in o.a.j.api.JackrabbitNodeTypeManager, and there we do validate all the QNames. If you are using NodeTypeRegistry directly, then I think it should be

Using the geronimo-jta dependency only in test scope

Hi, I traced where we use the javax.transaction interfaces currently included by jackrabbit-core via the geronimo-jta dependency. The extra interfaces are used quite a lot within the test cases, but in src/main/java only the o.a.j.core.TransactionContext and o.a.j.core.lock.XAEnvironment classes

[jira] Commented: (JCR-905) Clustering: race condition may cause duplicate entries in search index

[ https://issues.apache.org/jira/browse/JCR-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528043 ] Martijn Hendriks commented on JCR-905: -- I just tested Marcel's patch and it works fine. It's good to eliminate the

RE: Validation in QName class

Hi Jukka, If you do need the extra functionality from NodeTypeRegistry, how about if we exposed it on the JackrabbitNodeTypemanager level together with proper name validation? This solution would be cleaner design-wise and would allow you to drop one direct jackrabbit-core dependency.

Re: Synchronized methods in ItemManager

Julian Reschke wrote: Marcel Reutegger wrote: our official statement still is you may use multiple threads on a session that just read but a single thread on a session that writes. in - Could you please provide a pointer to that statement? well, maybe 'official' is the wrong term. whenever

Re: Synchronized methods in ItemManager

Marcel Reutegger wrote: Julian Reschke wrote: Marcel Reutegger wrote: our official statement still is you may use multiple threads on a session that just read but a single thread on a session that writes. in - Could you please provide a pointer to that statement? well, maybe 'official' is

Re: Synchronized methods in ItemManager

Hi, but I'm not convinced that guaranteeing more than JSR-170 says would be good for interoperability of clients. Maybe trying to detect concurrent access and throwing an exception would be an option? From HashMap javadocs: Fail-fast iterators throw ConcurrentModificationException on a

Re: System slowdown

Hi, I think the ObjectPersistenceManager should not be used. Maybe it is time to deprecate it... Is there some specific reason why you can't use a more modern persistence manager, for example BundleFsPersistenceManager or BundleDbPersistenceManager? As far as I know, both can access binary data

Re: Synchronized methods in ItemManager

Julian Reschke wrote: Marcel Reutegger wrote: Julian Reschke wrote: Marcel Reutegger wrote: our official statement still is you may use multiple threads on a session that just read but a single thread on a session that writes. in - Could you please provide a pointer to that statement?

Re: Using the geronimo-jta dependency only in test scope

El lun, 17-09-2007 a las 14:52 +0300, Jukka Zitting escribió: Hi, I traced where we use the javax.transaction interfaces currently included by jackrabbit-core via the geronimo-jta dependency. The extra interfaces are used quite a lot within the test cases, but in src/main/java only the

Re: release for Jackrabbit 1.4

Hi, On 9/11/07, ruchi goel [EMAIL PROTECTED] wrote: What is the expected time frame for release of Jackrabbit 1.4 ? I don't yet have any exact dates, but I'd expect at least a month or two before the release is ready. At least we still need to finalize the data store implementation and

[jira] Commented: (JCR-935) ConcurrentModificationException during logout (cont'd)

[ https://issues.apache.org/jira/browse/JCR-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528113 ] Esteban Franqueiro commented on JCR-935: We also sync'ed push() and getOverlayedState() in ItemState class.

[jira] Issue Comment Edited: (JCR-935) ConcurrentModificationException during logout (cont'd)

[ https://issues.apache.org/jira/browse/JCR-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524579 ] efranqueiro edited comment on JCR-935 at 9/17/07 11:56 AM: -- Regarding the NPE that

Re: Synchronized methods in ItemManager

Reading this post and going through some of the work I have done re. syncronization in the persistence manager I wonder if the real issue is not threads sharing a session, which it is clear they shouldn't, but that each session is tied to a persistence manager and an item manager which are

[jira] Updated: (JCR-1050) Remove synchronization from JNDI data sources

[ https://issues.apache.org/jira/browse/JCR-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated JCR-1050: Attachment: DerbyPooledPersistenceManager.java Here is a persistence manager which uses embedded

[jira] Created: (JCR-1139) Upgrading to Jackrabbit 1.3.1 - ERROR

Upgrading to Jackrabbit 1.3.1 - ERROR - Key: JCR-1139 URL: https://issues.apache.org/jira/browse/JCR-1139 Project: Jackrabbit Issue Type: Bug Components: config Affects Versions: 1.3.1