Hi!
+1 for all that Thomas said.
Andrey
From: Thomas Müller thomas.muel...@day.com
To: dev@jackrabbit.apache.org
Sent: Thu, 25 February, 2010 22:24:13
Subject: Re: [jr3] Synchronized sessions
Hi
http://issues.apache.org/jira/browse/JCR-2443.
Hi,
On Thu, Feb 25, 2010 at 10:24 PM, Thomas Müller thomas.muel...@day.com wrote:
http://issues.apache.org/jira/browse/JCR-2443.
Unfortunately this bug doesn't have a test case. Also I didn't find a
thread dump that shows what the problem was exactly. I can't say what
was the problem there.
WorkspaceImporter throws exception
--
Key: JCR-2521
URL: https://issues.apache.org/jira/browse/JCR-2521
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-core
[
https://issues.apache.org/jira/browse/JCR-2521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra resolved JCR-2521.
---
Resolution: Fixed
Fix Version/s: 2.1.0
fixed as suggested.
WorkspaceImporter throws
unable to workspace import XML.
---
Key: JCR-2522
URL: https://issues.apache.org/jira/browse/JCR-2522
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-jcr-server
[
https://issues.apache.org/jira/browse/JCR-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra resolved JCR-2522.
---
Resolution: Fixed
Fix Version/s: 2.1.0
fixed by accepting 2ndary mime type:
Sorry for top posting, I am not certain where to put this request.
Currently adding child nodes is almost serialised since its not possible to
merge concurrent changes in a single multi valued property.
*If* MVCC with abort on conflict is going to make this situation worse, then
that IMHO would
Hi Ian,
Could you describe your use case?
probability of conflict when updating a multivalued property is reduced
What methods do you call, and how should the conflict be resolved?
Example: if you currently use the following code:
1) session1.getNode(test).setProperty(multi, new String[]{a,
Hi,
On Thu, Feb 25, 2010 at 19:14, Felix Meschberger fmesc...@gmail.com wrote:
Hi,
On 25.02.2010 17:55, Marcel Reutegger wrote:
Hi,
On Thu, Feb 25, 2010 at 15:49, Felix Meschberger fmesc...@gmail.com wrote:
Hi,
On 24.02.2010 21:19, Thomas Müller wrote:
Hi,
deadlocks
I think it's
Hi,
On 26.02.2010 14:38, Marcel Reutegger wrote:
Hi,
On Thu, Feb 25, 2010 at 19:14, Felix Meschberger fmesc...@gmail.com wrote:
Hi,
On 25.02.2010 17:55, Marcel Reutegger wrote:
Hi,
On Thu, Feb 25, 2010 at 15:49, Felix Meschberger fmesc...@gmail.com wrote:
Hi,
On 24.02.2010 21:19,
Hi,
On Fri, Feb 26, 2010 at 6:36 PM, Felix Meschberger fmesc...@gmail.com wrote:
Consider two threads T1 and T2 each modifying data from the same session:
T1 makes some modifications
T2 makes some modifications
T1 saves the session (incl. both T1's and T2's modifs)
T2 makes some more
On Fri, Feb 26, 2010 at 6:11 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
All we're trying to achieve here is ensure internal consistency even
when clients do something like the above (for whatever reason,
intentional or not).
jdbc connection is not thread safe.
jcr session works similar
[
https://issues.apache.org/jira/browse/JCR-2426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonio Martinez updated JCR-2426:
--
Attachment: deadlock_jackrabbit1.6.txt
Deadlock in lucene (Jackrabbit 1.4.4)
Hi,
On 26.02.2010 19:11, Jukka Zitting wrote:
Hi,
On Fri, Feb 26, 2010 at 6:36 PM, Felix Meschberger fmesc...@gmail.com wrote:
Consider two threads T1 and T2 each modifying data from the same session:
T1 makes some modifications
T2 makes some modifications
T1 saves the session (incl.
14 matches
Mail list logo
