[jboss-jira] [JBoss JIRA] Updated: (JBCACHE-766) Don't return unnecessary values from _replicate, avoiding need for marshalling

[Manik Surtani (JIRA)]

     [ http://jira.jboss.com/jira/browse/JBCACHE-766?page=all ]

Manik Surtani updated JBCACHE-766:
----------------------------------

    Fix Version/s: 1.4.0.SP2
                   2.0.0

Hacky, agreed, but effective.  :-)

In fact, I think this (as a concept) should be integrated to JBCACHE-752 (and I will x-reference accordingly) but for the 1.4.0 series, this patch can be introduced without breaking compatibility.

Extending the patch to cover remove(fqn, key) as well.

> 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