Thanks Peter.  The plan is for Dmitry and I to at first extend VanillaSharedHashMap and groom it into an ISPN7 join via their DataContainer API bridge.

That ExtendedVSHM will be morphed into a fully inter-operable JCACHE operand will

- initially be brokered by the ISPN 7 config  (JSR107 <----> VSHMExtendedDataContainer <----> VSHM)
- eventually, possibly, be rendered with ExtendedVSHM directly implementing javax.cache.Cache (in addititon to DataContainer)

On 03/07/2014 11:43 AM, Peter Lawrey wrote:

In the medium term I would see SHM supporting a DataContainer. If a Cache were supported I would do it as a layered class so those who don't need the functionality of a Cache don't incur an overhead.

On 8 Mar 2014 03:35, "Ben Cotton" <[hidden email]> wrote:
Thank you for this insight Mircea ...

Ultimately ... I want the OpenHFT SHM off-heap operand to behave *exactly* like a JCACHE ... Amenable to being soundly/completely operated upon by any/all parts of ISPN7's Impl of the JSR-107 API .

Musing openly:  Won't that (eventually) necessitate me physically implementing javax.cache.Cache ?

>  Another way to do it is to have CacheImpl implement the DataContainer only, and then configure Infinispan's JCache implementation to use that custom DataContainer.

I see what you mean.  OK, for sure, this sounds much simpler than what I have put on my initial TODO list.

Question:  Will doing it this way  in any manner suggest that my JSR-107 specific operators are  being transitively "brokered" by the ISPN config onto my OpenHFT SHM operand?  If possible, I want everything to be direct -- no API bridge.

Thanks again, Mircea.

-Ben and Dmitry

Sent from my iPhone
On 03/07/2014 09:45 AM, Mircea Markus-2 [via Infinispan Developer List] wrote:
Hi Ben,

In the diagram provided, the CacheImpl (your class) extends both from javax.cache.Cache and org.infinispan.container.DataContainer.
The Cache and DataContainer interfaces are quite different and I anticipate an single class implementing both to be hard to follow and potentially not very efficient.
Another way to do it is to have CacheImpl implement the DataContainer only, and then configure Infinispan's JCache implementation to use that custom DataContainer.

On Mar 3, 2014, at 3:46 PM, cotton-ben <[hidden email]> wrote:

> Quick Update:
>
> It is my understandng that Peter Lawrey will make available  an OpenHFT HC
> Alpha Release in Maven Central next weekend. At that time, Dmitry Gordeev
> and I will take the OpenHFT dependency tag and proceed to build a branch of
> Red Hat's ISPN 7 that will treat net.openhft.collections.SharedHashMap as a
> Red Hat Infinispan 7 default impl of a fully JSR-107 interoperable off-heap
> javax.cache.Cache ...
>
> A diagram of this build effort can be found here:
> https://raw.github.com/Cotton-Ben/OpenHFT/master/doc/AdaptingOpenHFT-SHM-as-JCACHE-Impl.jpg
> ...
>
> The Red Hat view of his effort will be tracked here:
> https://issues.jboss.org/browse/ISPN-871  ...
>
> The code that defines the Impl will be here
> https://github.com/Cotton-Ben/infinispan ...
>
>
>
>
>
> --
> View this message in context: http://infinispan-developer-list.980875.n3.nabble.com/infinispan-dev-Infinispan-embedded-off-heap-cache-tp4026102p4028931.html
> Sent from the Infinispan Developer List mailing list archive at Nabble.com.
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)





_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


To start a new topic under Infinispan Developer List, email [hidden email]
To unsubscribe from [infinispan-dev] Infinispan embedded off-heap cache, click here.
NAML



View this message in context: Re: [infinispan-dev] Infinispan embedded off-heap cache
Sent from the Infinispan Developer List mailing list archive at Nabble.com.