[infinispan-issues] [JBoss JIRA] (ISPN-7420) Hot Rod enhancements for transcoding

[Gustavo Fernandes (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-7420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13557999#comment-13557999 ] 

Gustavo Fernandes commented on ISPN-7420:
-----------------------------------------

Some comments:

| Once the first cache write has determined the key+value types, the clients do not need to send them again. If the client sends different types for the same cache, it should either result in the server ignoring it or an error (the former is preferable). To avoid sending unnecessary data, advanced clients could cache the key+value type for a given cache after the first write request and then don't send it again.

This would require a sort of Session in the server, keeping state per client, which makes the implementation more complex. Also, "first write" is not as trivial as it seems. Writes can come from several sources, such as state transfer, replication, rest, scripts, etc. Coordinating those will also increase complexity: as different clients can compete for the "first write" each one with different MediaTypes. I'd rather no go to that route.

Furthermore, I'd prefer to allow users to choose the media on a per request basis. Since the MediaType is configured in the server, whatever data format used by the client can be converted to the storage format.

What I propose is a similar approach to the REST client: user can optionally configure MediaType in the server caches, and in every Hot Rod request it can send mime type for keys and values. This would allow to send JSON and read back protostream, for example, in two different requests. Since the MimeType is sent for every request, no state per client is maintained in the server, there is no need to identify the first write. Regarding wire format, the most commons MediaTypes (covering 99% of use cases) can be serialized efficiently by using a fixed id Table

> Hot Rod enhancements for transcoding
> ------------------------------------
>
>                 Key: ISPN-7420
>                 URL: https://issues.jboss.org/browse/ISPN-7420
>             Project: Infinispan
>          Issue Type: Feature Request
>            Reporter: Galder Zamarreño
>            Assignee: Gustavo Fernandes
>
> Several enhancements will need to be made to the Hot Rod protocol to work with transcoding:
> h3. Cache Writes (key + value)
> * Cache write operations that include values should have an optional parameter to be able to define the MIME type of the key and value that is being written. When the optional parameter is sent to the server, it will enable the server to implicitly discover what the types of the key+value are.
> * Once the first cache write has determined the key+value types, the clients do not need to send them again. If the client sends different types for the same cache, it should either result in the server ignoring it or an error (the former is preferable).
> * To avoid sending unnecessary data, advanced clients could cache the key+value type for a given cache after the first write request and then don't send it again.
> h3. Cache reads
> * Any operation that involves retrieving data should optionally take the type that the value should be transcoded to when returning it back to the client. This enables data to be read in different formats.
> * Within these operations, write operations that return previous values should be included.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)