On Wed, Feb 24, 2010 at 9:03 PM, Felix Meschberger fmesc...@gmail.com wrote:
A big -1 (I already see the deadlocks in front of me)
if there are deadlocks caused by such a change then the api's clearly being
misused (i.e. concurrent use of session instances) and there's a risk of data
corruption.
Hi,
On Thu, Feb 25, 2010 at 9:22 AM, Stefan Guggisberg
stefan.guggisb...@gmail.com wrote:
On Wed, Feb 24, 2010 at 9:03 PM, Felix Meschberger fmesc...@gmail.com wrote:
A big -1 (I already see the deadlocks in front of me)
if there are deadlocks caused by such a change then the api's clearly
On Wed, Feb 24, 2010 at 19:34, Thomas Müller thomas.muel...@day.com wrote:
I believe it's better to synchronize all methods in the session (on
the session object). This includes methods on nodes and properties and
so on. If this does turn out to be a performance problem, we can
remove
[
https://issues.apache.org/jira/browse/JCR-2433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12838284#action_12838284
]
Sascha Theves commented on JCR-2433:
Is there a way to manually fix the problem? We have
Make ItemIds more stable
Key: JCR-2518
URL: https://issues.apache.org/jira/browse/JCR-2518
Project: Jackrabbit Content Repository
Issue Type: Improvement
Components: jackrabbit-spi2dav
Affects
[
https://issues.apache.org/jira/browse/JCR-2518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated JCR-2518:
---
Attachment: JCR-2518.patch
Proposed patch
Make ItemIds more stable
On Thu, Feb 25, 2010 at 10:05, Jukka Zitting jukka.zitt...@gmail.com wrote:
Hi,
On Thu, Feb 25, 2010 at 9:22 AM, Stefan Guggisberg
stefan.guggisb...@gmail.com wrote:
On Wed, Feb 24, 2010 at 9:03 PM, Felix Meschberger fmesc...@gmail.com
wrote:
A big -1 (I already see the deadlocks in front
On Tue, Feb 23, 2010 at 15:03, Jukka Zitting jukka.zitt...@gmail.com wrote:
Hi,
On Sat, Feb 20, 2010 at 1:16 PM, Thomas Müller thomas.muel...@day.com wrote:
I would like to define a new storage format for nodes and properties.
More generally, I'd like to raise the bundle abstraction to a
Thomas,
== Proposed Solution ==
When adding/changing/removing a property or node, the logical
operation should be recorded on a high level (this node was added,
this node was moved from here to there, this property was added),
first in memory, but when there are changes, it needs to be
On Thu, Feb 25, 2010 at 13:28, Michael Dürig michael.due...@day.com wrote:
I like this approach. In general I think merging is very difficult if not
impossible at all to get right and will always be based on some assumptions
(intended semantics). I think we should not put this burden onto the
spi2davex: use srcWorkspaceName to build srcPath for clone and copy
---
Key: JCR-2519
URL: https://issues.apache.org/jira/browse/JCR-2519
Project: Jackrabbit Content Repository
Alexander Klimetschek wrote:
On Thu, Feb 25, 2010 at 13:28, Michael Dürig michael.due...@day.com wrote:
I like this approach. In general I think merging is very difficult if not
impossible at all to get right and will always be based on some assumptions
(intended semantics). I think we should
[
https://issues.apache.org/jira/browse/JCR-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved JCR-2519.
-
Resolution: Fixed
Fix Version/s: 2.1.0
Assignee: angela
spi2davex: use srcWorkspaceName to build
[
https://issues.apache.org/jira/browse/JCR-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12838336#action_12838336
]
angela commented on JCR-2104:
-
Revision: 916278 [work in progress]
jcr2spi:
- simplify
There are low level merge and high level merge. A low level
merge is problematic it can result in unexpected behavior. I would
even say the way Jackrabbit merges changes currently (by looking at
the data itself, not at the operations) is problematic.
Example: Currently, orderBefore can not be
[
https://issues.apache.org/jira/browse/JCR-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12838336#action_12838336
]
angela edited comment on JCR-2104 at 2/25/10 1:42 PM:
--
Revision: 916278
[
https://issues.apache.org/jira/browse/JCR-2518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig resolved JCR-2518.
Resolution: Fixed
Fix Version/s: 2.1.0
Fixed at revision: 916295
Make ItemIds more stable
[
https://issues.apache.org/jira/browse/JCR-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephan updated JCR-2503:
-
Attachment: JCR-2503.patch
inconsistent session and persistent state after ReferentialIntegrityException
Hi,
On 24.02.2010 21:19, Thomas Müller wrote:
Hi,
deadlocks
I think it's relatively simple to synchronize all methods on the session.
Yes, but this creates a big potential for deadlocks ...
If we want to make sessions thread-safe, we should use proper
implementations.
Yes, that's
Hi,
On 25.02.2010 10:05, Jukka Zitting wrote:
Hi,
On Thu, Feb 25, 2010 at 9:22 AM, Stefan Guggisberg
stefan.guggisb...@gmail.com wrote:
On Wed, Feb 24, 2010 at 9:03 PM, Felix Meschberger fmesc...@gmail.com
wrote:
A big -1 (I already see the deadlocks in front of me)
if there are
Most jcr apps I've seen often use a single session from several threads
to read from this session. (I think I also read it somewhere that this
is safe with jackrabbit, but I might be mistaken).
Simply syncing everything on the session would decrease performance in
these cases dramatically.
[JBoss] No ManagedConnections available / JCA max connection (session)
--
Key: JCR-2520
URL: https://issues.apache.org/jira/browse/JCR-2520
Project: Jackrabbit Content Repository
On Thu, Feb 25, 2010 at 3:59 PM, Felix Meschberger fmesc...@gmail.com wrote:
Hi,
On 25.02.2010 10:05, Jukka Zitting wrote:
Hi,
On Thu, Feb 25, 2010 at 9:22 AM, Stefan Guggisberg
stefan.guggisb...@gmail.com wrote:
On Wed, Feb 24, 2010 at 9:03 PM, Felix Meschberger fmesc...@gmail.com
[
https://issues.apache.org/jira/browse/JCR-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12838377#action_12838377
]
Cédric Chantepie commented on JCR-2520:
---
Test case that tries to open more than 20
[
https://issues.apache.org/jira/browse/JCR-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12838378#action_12838378
]
Cédric Chantepie commented on JCR-2520:
---
Connection conn = null;
PreparedStatement stmt
Hi,
this creates a big potential for deadlocks
Could you provide an example on how such a deadlock could look like?
just synchronizing all methods
So you also synchronize all Node/Item/Property methods
Some methods don't need to be synchronized, for example some getter
methods such as
On Thu, Feb 25, 2010 at 4:03 PM, Carsten Ziegeler cziege...@apache.org wrote:
Most jcr apps I've seen often use a single session from several threads
to read from this session. (I think I also read it somewhere that this
is safe with jackrabbit, but I might be mistaken).
that's an unsupported
Hi,
On 25.02.2010 16:34, Stefan Guggisberg wrote:
On Thu, Feb 25, 2010 at 4:03 PM, Carsten Ziegeler cziege...@apache.org
wrote:
Most jcr apps I've seen often use a single session from several threads
to read from this session. (I think I also read it somewhere that this
is safe with
Hi,
On 25.02.2010 16:33, Thomas Müller wrote:
Hi,
this creates a big potential for deadlocks
Could you provide an example on how such a deadlock could look like?
I don't have an example off hand, and as Jukka said, it might well be,
that there might be none. Still the potential exists,
On Thu, Feb 25, 2010 at 4:54 PM, Felix Meschberger fmesc...@gmail.com wrote:
Hi,
On 25.02.2010 16:34, Stefan Guggisberg wrote:
On Thu, Feb 25, 2010 at 4:03 PM, Carsten Ziegeler cziege...@apache.org
wrote:
Most jcr apps I've seen often use a single session from several threads
to read from
Stefan Guggisberg wrote:
On Thu, Feb 25, 2010 at 4:03 PM, Carsten Ziegeler cziege...@apache.org
wrote:
Most jcr apps I've seen often use a single session from several threads
to read from this session. (I think I also read it somewhere that this
is safe with jackrabbit, but I might be
Hi folks,
I am new to this list and to Jackrabbit. My interest lies mainly in JCR
rather than Jackrabbit per se...
I downloaded and started running Jackrabbit on top of my own webapp. Very
smooth beginning, no probs. I wanted to play around with security so I:
(a) had a look at repository.xml
[
https://issues.apache.org/jira/browse/JCR-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12838398#action_12838398
]
Cédric Chantepie commented on JCR-2520:
---
It seems that the limit cames from the
Hi,
Consider two or more threads reading different items at the same time:
they all are chained one after the other.
Only if those threads use the same session.
this is unsupported, yet you want to add synchronization to secure
this unsupported case ...
When we are done it becomes a
On Thu, Feb 25, 2010 at 5:10 PM, Carsten Ziegeler cziege...@apache.org wrote:
Stefan Guggisberg wrote:
On Thu, Feb 25, 2010 at 4:03 PM, Carsten Ziegeler cziege...@apache.org
wrote:
Most jcr apps I've seen often use a single session from several threads
to read from this session. (I think I
All comments result from my experiences with Jackrabbit 1.6. Version
1.6 is a weird beast because it contains a full JCR 1.0 implementation
with some JCR 2.0 implementation too. (But the JCR 2.0 implementation
isn't against the standard JCR 2.0 interfaces.) So AccessControlManager
(a JCR 2.0
[
https://issues.apache.org/jira/browse/JCR-2442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated JCR-2442:
---
Attachment: JCR-2442.patch
Possible patch.
Since JCR-2498 should fix some of the observed performance
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 relatively simple to synchronize all methods on the session.
Yes, but this creates
Hi
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.
Observation is definitely an area where synchronization can
potentially lead to
Thanks for the clarification.
What I am doing now is extend AbstractAccessControlManager and implement
AccessManager.
I still use the same config in repository.xml:
AccessManager
class=org.apache.jackrabbit.core.security.simple.AnotherAccessManager
!-- param name=config
40 matches
Mail list logo
