Ok, some exploration has shed a bit more light here. In fact, the
select count(*) is happening because I'm using ODMG and it's a part of
the locking procedure. Specifically, at line 273 of ObjectEnvelope
(from CVS HEAD) there's a call to size(), accompanied by this comment:
/**
* MBAIRD
* size isn't the safest thing to use as the dirty bit. This will
* need to be fixed.
*/
if(collectionOrArray instanceof Collection)
{
referencesId = ((Collection) collectionOrArray).size();
}
else if(collectionOrArray.getClass().isArray())
{
referencesId = Array.getLength(collectionOrArray);
}
else
{
referencesId = collectionOrArray.hashCode();
}
fieldValues.put(collectionDescriptor, new Integer(referencesId));
Is there some way that I can avoid making all of these size() calls on
my collection proxies? Have there been any discussions about what to
use as the dirty bit instead of the size? Perhaps a simplification
would be to at least add a case for the known collection proxy
classes:
if(collectionOrArray instanceof CollectionProxyDefaultImpl)
{
referencesId = ((CollectionProxyDefaultImpl)
collectionOrArray).getWriteCount();
}
else if(collectionOrArray instanceof Collection)
...
I may explore this one, because I need to get rid of these queries ...
--
Steve Clark
Technology Applications Team
Natural Resources Research Center/USGS
[EMAIL PROTECTED]
(970)226-9291
>>>>> Steve Clark writes:
sc> Why does a collection proxy need to know its size a priori?
sc> I'm trying to use collection proxies to minimize DB activity
sc> when materializing a large number of top-level objects, but I
sc> still end up getting hundreds of "select count(*)" queries for
sc> collections I will never look at. They aren't even batched by
sc> the prefetching mechanism. Is there any hope? Why can't the
sc> count be deferred until needed, just like the actual
sc> collection contents?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
