Also you explicitly put the "deferred implementation" words in your response.
Are you speculating that the non-deferred implementation would likely not
suffer this problem of the reference count? I'd probably still have thread
safety issues, but might not run into children going away?
I think
Thanks Michael. That's the response I've been waiting for. This whole
situation is really unfortunate, since it's not even my code that is missing
the required locking, and the developers of that faulting code have pretty
decent justification for refusing to add it. I'll try to push back on t
"Newman, John W" wrote on 06/08/2011 01:24:38 PM:
> I?ve thought about document pooling but I don?t think that?s very
> scalable. These elements themselves are about 500k, the document
> has about 20 of these elements. And I have ~16 organizations each
> with their own document. We?re alread
>> > next sibling to return the result. Without that optimization the time
>> > spent
>> > iterating over the NodeList would be O(n^2) instead of linear.
>>
>> Ah ok, so there is some saved state going on. Next question, what
>> makes iterating over the list n-squared?
>
> It's a linked list which
Andrew Welch wrote on 06/09/2011 08:19:18 AM:
> Please respond to j-users
>
> >> Imagine a List class with a "length()" method. The first time the
> >> length() method is called it walks the list and then stores the size
> >> internally to a variable so that future calls to length() return th
>> Imagine a List class with a "length()" method. The first time the
>> length() method is called it walks the list and then stores the size
>> internally to a variable so that future calls to length() return this
>> size.
>> The data model hasn't changed, but the actual implementation state dat
"David Lee" wrote on 06/09/2011 07:35:07 AM:
> -
> > So in some implementations of any class ... 'read' methods may or may
not
> be
> > thread safe depending on the implementation.
>
> Even if the underlying data is fixed and doesn't change?
>
>
> "it depends" on
-
> So in some implementations of any class ... 'read' methods may or may not
be
> thread safe depending on the implementation.
Even if the underlying data is fixed and doesn't change?
"it depends" on the implementation.
One can write thread-safe code and one can
> So in some implementations of any class ... 'read' methods may or may not be
> thread safe depending on the implementation.
Even if the underlying data is fixed and doesn't change?
--
Andrew Welch
http://andrewjwelch.com
-
FYI the term 'read only' is a convention not a enforcement in java.
In Java, methods cannot be annotated as 'read only' so its a convention
which may or may not be known to the user what methods may affect the
underlying model.
In C++ its slightly better as you can annotate a method as 'const' whi
As per the discussions on this thread, the DOM implementations even when
you only do only 'read' operations are not thread safe.
David A. Lee
d...@calldei.com
http://www.xmlsh.org
-Original Message-
From: Andrew Welch [mailto:andrew.j.we...@gmai
On 9 June 2011 10:57, David Lee wrote:
> Along this lines, there are thread save read-only XML tree models available,
> just not DOM.
> Saxon's tree model is thread safe during read operations. I believe XOM is
> as well (not 100%).
How can anything that is read-only not be thread safe?
--
Along this lines, there are thread save read-only XML tree models available,
just not DOM.
Saxon's tree model is thread safe during read operations. I believe XOM is as
well (not 100%).
David A. Lee
d...@calldei.com
http://www.xmlsh.org
-Original
13 matches
Mail list logo
