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 ItemM
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
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 ItemManag
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 -
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 applica
[
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 NodeEn
[
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
> --
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
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
[
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
d
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 o
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
> {htt
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
> > reg
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 th
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
> NodeTypeRegistry.validate
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
> > NodeTy
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
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 sho
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 u
[
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
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
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
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
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 best-
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 mo
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?
wel
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
> 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 implementati
[
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.
Rega
[
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 Pabl
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 both
[
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 derb
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
[
https://issues.apache.org/jira/browse/JCR-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rama Krishna updated JCR-1139:
--
Attachment: repository.xml
RepositoryServlet.java
jaas.config
my app conf
[
https://issues.apache.org/jira/browse/JCR-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting resolved JCR-1139.
Resolution: Invalid
Assignee: Jukka Zitting
What's the 1.0-4 version you were using earlier? Th
35 matches
Mail list logo