Hello,
I have a problem with the following use-case: A user reads the current
value of a property of a node, then makes a decision based upon the read
value and changes the value.
Is there any way, besides locking, to makes this use-case atomic... thus
enabling a kind of a testset-mechanism?
Hi,
On Fri, Mar 12, 2010 at 10:17 AM, Dan Diephouse
dan.diepho...@mulesource.com wrote:
Can I assume this is a bug and file a JIRA? Seems like rather big problem to
me.
Yes, as far as I can tell your code should work as expected.
BR,
Jukka Zitting
Hi Dan, I saw this issue before. I have read this too but in my test cases
it is always throwing the same exception: InvalidItemState.
My understanding was that a merge should happens if there is no same-name
siblings.
My 2 cents
On Fri, Mar 12, 2010 at 1:17 AM, Dan Diephouse
Can I assume this is a bug and file a JIRA? Seems like rather big problem to
me.
2010/3/8 Dan Diephouse dan.diepho...@mulesource.com
My impression was that as long as you do not have same name siblings,
concurrent additions are allowed:
I'm having some problems doing concurrent addition of nodes to a parent node
in Jackrabbit. I'm probably doing something stupid and I'm wondering if
someone can comment on what that might be.
I've attached a simple test which starts up a bunch of threads which add
nodes to a parent node
On Mon, Mar 8, 2010 at 13:18, Dan Diephouse
dan.diepho...@mulesource.com wrote:
I'm having some problems doing concurrent addition of nodes to a parent node
in Jackrabbit. I'm probably doing something stupid and I'm wondering if
someone can comment on what that might be.
I've attached a
My impression was that as long as you do not have same name siblings,
concurrent additions are allowed:
http://n4.nabble.com/Problem-in-Multithreaded-Environment-tp516406p516415.html
2010/3/8 Alexander Klimetschek aklim...@day.com
On Mon, Mar 8, 2010 at 13:18, Dan Diephouse
