On 14 Dec 2006, at 20:42, Galder Zamarreno wrote:
I'm in the process of integrating VersionAwareMarshaller with
JBDCCacheLoader and I've found an issue in TreeCacheMarshaller200.
Let's say I make a put (single key/value pair) in the cache which
results in an insert of a marshalled map in the db. I then call
remove(key) which results on the map still being in the db but
containing no data.
If I evict the data from memory and call put() again, unmarshallMap
() would return Collections.emptyMap() which returns an immutable
empty map. When I try putting my new data into the map, it throws
java.lang.UnsupportedOperationException which is expected as the
map is immutable.
I had a quick chat with Brian and the first solution was to check
for isEmpty() but as Brian pointed out,
"If VAM is meant to be a general purpose tool, it needs to work in
a general purpose way, if code that uses it needs to understand
it's internal details and code around them, that's improper"
He also said: "well VAM is just assuming that the only purpose of
the map is to be an argument in a put call. if VAM is to be
general purpose it can't make such assumptions, or needs to expose
an API to turn them on/off per request"
I think Brian is right. Currently, JDBCCL checks values from
JDBCCL.loadNode() based on the contract of this method, and
therefore, should not really now what could come from VAM.
I'd treat TCM200.unmarshallMap() returning Collections.emptyMap() as
a bug! It should return a *usable* map even if it is empty. I
probably used this as a short-sighted optimisation.
if (mapSize == 0) return new HashMap(); //much better/more
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
IT executives: Red Hat still #1 for value http://www.redhat.com/
jbosscache-dev mailing list