[
http://jira.jboss.com/jira/browse/JBCACHE-766?page=comments#action_12343197 ]
Owen Taylor commented on JBCACHE-766:
-------------------------------------
But that return value isn't needed for replication. So, this
patch just nulls out the return value
from the two affected methods.
That's sort of unclear, actually. To clarify: it nulls out the return values when
returning them from
_replicate. The actual underlying methods are unmodified.
Don't return unnecessary values from _replicate, avoiding need
for marshalling
------------------------------------------------------------------------------
Key: JBCACHE-766
URL:
http://jira.jboss.com/jira/browse/JBCACHE-766
Project: JBoss Cache
Issue Type: Patch
Security Level: Public(Everyone can see)
Components: Clustering
Affects Versions: 1.4.0.SP1
Reporter: Owen Taylor
Assigned To: Manik Surtani
Priority: Minor
Fix For: 1.4.0.SP2
Attachments: jbosscache-avoid-return-20060912.patch
This is somewhat related to JBCACHE-752, which suggests setting a marshaller for
responses passed over RpcDispatcher as well as for requests, but is a simpler and
less general fix.
Right now if you set a class loader for a tree cache region, it works for request
parameters,
but is ignored for returns. If there is an attempt to return a value that needs to be
loaded
with the class loader, an exception will be thrown.
The only return value in normal REPL_SYNC operation is the return value from
the key-value put methods, which is the old value, if any. But that return value
isn't
needed for replication. So, this patch just nulls out the return value from the two
affected
methods.
(We're setting a class loader to deal with the fact that enumerations fields of
Hibernate
entities are stored directly in the cache, and are serialized/deserialized on
replication.
There's a JIRA entry for that issue, which likely should be fixed in Hibernate by
storing
such fields as ordinals, but I think this patch is a legitimate TreeCache fix, if done in
a slightly
hacky manner.)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira