[
https://issues.redhat.com/browse/ISPN-10373?page=com.atlassian.jira.plugi...
]
Will Burns commented on ISPN-10373:
-----------------------------------
Here is the current prototype for the metadata methods for new stores. It will not make it
in this JIRA but possibly in a future.
{code}
/**
* Provides a way for the store to communicate which media type it requires for its key
arguments. Infinispan
* will invoke this method immediately after the store is started providing the media
type that in memory objects are
* stored via {@code storageMediaType} as well as all the media types this running
instance can support converting
* to. The store then must choose from any of the provided media types. Any methods
that are invoked after that
* accept a key argument will be guaranteed to have this key be in the desired media
type. Also any return values
* from this store should be in this media type
* <p>
* Note that choosing a media type other than the storage media type will incur the
cost of converting the key
* to and from the storage media type for input and output parameters.
* <p>
* TODO: update once this detection is more explicit
* Note that if the returned MediaType is binary, that the provided and returned values
will/must be raw unwrapped
* byte[] instances. Due to this the users should not rely upon the equality of such
instances as each instance
* will possibly be different objects.
* <p>
* The {@link MediaType#MATCH_ALL} is a special media type that if returned will signal
that the store should
* receive all values
* @implSpec
* The default implementation just returns the storageMediaType
* @param storageMediaType how the key is stored in memory
* @param supportedMediaTypes what media types Infinispan can convert to automatically
on behalf of the store
* @return the media type the store desires for keys to be in when invoked and will
return in
*/
default MediaType getKeyMediaType(MediaType storageMediaType, Set<MediaType>
supportedMediaTypes) {
return storageMediaType;
}
/**
*
* @param storageMediaType
* @param supportedMediaTypes
* @return
*/
default MediaType getValueMediaType(MediaType storageMediaType, Set<MediaType>
supportedMediaTypes) {
return storageMediaType;
}
{code}
Store/Loader Non blocking SPI
-----------------------------
Key: ISPN-10373
URL:
https://issues.redhat.com/browse/ISPN-10373
Project: Infinispan
Issue Type: Feature Request
Components: Loaders and Stores
Reporter: Will Burns
Assignee: Will Burns
Priority: Major
We need to add and use a non blocking SPI internally for our stores/loaders. We added
ISPN-9722, which is a good step and refactored all of our internal code to use "non
blocking" stores. However the stores themselves are all inherently sync even if the
store itself could be non blocking. We would have to add a new SPI interface to allow for
such non blocking operations. We would then remove all the explicit threading added in
ISPN-9722 and move it to a wrapper around a currently sync loader instead. This way an
invoking thread doesn't need to do a context switch or anything if invoking just a non
blocking store operation.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)