Hi John,
"Newman, John W" <newma...@d3onc.com> wrote on 06/09/2011 12:56:07 PM:
> 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?
The non-deferred implementation doesn't have those tables.
The code I'm thinking about in particular is in DeferredDocumentImpl:
private final int clearChunkIndex(int data[][], int chunk, int index) {
int value = data[chunk] != null ? data[chunk][index] : -1;
if (value != -1) {
data[chunk][CHUNK_SIZE]--;
data[chunk][index] = -1;
if (data[chunk][CHUNK_SIZE] == 0) {
data[chunk] = null;
}
}
return value;
}
private final String clearChunkValue(Object data[][],
int chunk, int index) {
String value = data[chunk] != null ? (String)data[chunk][index] :
null;
if (value != null) {
data[chunk][index] = null;
RefCount c = (RefCount) data[chunk][CHUNK_SIZE];
c.fCount--;
if (c.fCount == 0) {
data[chunk] = null;
}
}
return value;
}
These methods would never be called by the non-deferred implementation.
> I?d probably still have thread safety issues, but might not run into
> children going away?
It's one less thing to worry about. The deferred implementation is much
more volatile than the non-deferred one.
> I think for starters I?ll try out turning off the deferred parsing
> and see. The way these documents are used, it doesn?t take too long
> for all of the users to walk down to all the different leaves, I?d
> imagine after a few hours the deferred parsing isn?t really doing
> much -everything has already been touched.
Thanks.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrgla...@ca.ibm.com
E-mail: mrgla...@apache.org
