[JBoss JIRA] (ISPN-2766) Improve and adapt notification model to fit JSR107 notification model
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2766?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-2766:
-----------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1686
> Improve and adapt notification model to fit JSR107 notification model
> ---------------------------------------------------------------------
>
> Key: ISPN-2766
> URL: https://issues.jboss.org/browse/ISPN-2766
> Project: Infinispan
> Issue Type: Sub-task
> Components: Listeners
> Affects Versions: 5.2.0.CR3
> Reporter: Vladimir Blagojevic
> Assignee: Galder Zamarreño
> Fix For: 5.3.0.Alpha1
>
>
> Out current notification (listener) model does not fit JSR 107 notification model and thus needs a slight adaptation in order to implement JSR 107.
> More specifically the problem is with JSR107 CacheEntryCreatedListener and CacheEntryExpiredListener.
> The first one is not easy to implement because we need both key/value pair for jsr listener and our CacheEntryCreatedEvent does not provide value.
> The second is related to CacheEntryExpired event. True, spec is not rigorous that such an event has to be fired immediately after an entry has expired but eventually (which might be on access). However, we do not have such an event at all as of now.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (ISPN-2767) Retrofit storeAsBinary to allow implementation of JSR107 store by value
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2767?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-2767:
-----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1686
> Retrofit storeAsBinary to allow implementation of JSR107 store by value
> ------------------------------------------------------------------------
>
> Key: ISPN-2767
> URL: https://issues.jboss.org/browse/ISPN-2767
> Project: Infinispan
> Issue Type: Sub-task
> Components: Core API, Marshalling
> Affects Versions: 5.2.0.CR3
> Reporter: Vladimir Blagojevic
> Assignee: Galder Zamarreño
> Fix For: 5.3.0.Alpha1
>
>
> storeAsBinary in Infinispan was designed with the following purposes in mind, in order of importance:
> 1) Performance. Prevent serialising/deserializing an entry multiple times (e.g., to write through to disk, to replicate over the network, concurrent threads needing to read the object representation).
> 2) Classloader isolation (as Galder mentioned). This became a secondary purpose of this feature (originally observed as a side-effect). Enhanced by allowing storeKeyAsBinary and storeValueAsBinary options for more fine-grained control of this behaviour.
> Now lets consider what JSR 107 needs. Similarly named, the feature in JSR 107 serves a completely different purpose, and this is referential integrity. Think database-style isolation (repeatable read, etc) where concurrent threads holding object references to the same value, and mutating the same value, are not visible until a commit.
> I originally thought that Infinispan's storeAsBinary can be used for this, but apparently not without some additional changes/tweaks. Maybe we need:
> 1) A new config option for this behaviour. <storeAsBinary defensive="true" /> ?
> 2) If enabled, maybe use a subclass of MarshalledValue (DefensiveMarshalledValue?) that *always* stores a byte[] and never caches the object representation?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months