[infinispan-dev] L1 Data Container

[cotton-ben]

> I have to disagree ;-) It certainly is a fact that he's very well
> intentioned to make enhancements, but I don't this strategy is proven
> the be superior; I'm actually convinced of the opposite.

> We simply cannot assume that the "real data" and the L1 stored entries
> will have the same level of hotness,

L1 stored entries are "real data" -- right?  I mean, yes,  they are
non-permanent custodians of "real data".  But certainly they should be able
to be transparently viewed (through an empowering API) as real data.

Also - IMHO- the "same level of hotness" metric should be a user-decided
concept that the user chooses and subsequently operates on (through an
empowering API).

I guess I agree that we have to disagree, Sanne.  For us, William's ambition
to provide an L1-specific focus for enhanced capability (and API) is
extremely attractive.  The distinction of "what manifests an L1 capability"
is historically very significant.

Consider these physical views of traditional L1 (and L2, ...,Ln)
resources/capabilities and the traditional use cases for operating on/with
those capabilities.  

https://community.jboss.org/servlet/JiveServlet/download/823936-95446/L1L2PhysicalView.jpg 

https://community.jboss.org/servlet/JiveServlet/download/823936-95446/L1L2PhysicalView.jpg

https://community.jboss.org/servlet/JiveServlet/download/823889-95415/ParetoDistributionAndL1L2JoinPoint.jpg

How are these traditional views relevant to modern (potetnial) ISPN
deployments?  Just consider if I have a non-homogenous set of (highly
specialized for locality/latency requirements) resources backing the ISPN
nodes participating in my full DIST_SYNC grid  (e.g.  L1 view=elite ISPN JVM
nodes exec on super-computer on physical network=Infinband, L2 view=ordinary
ISPN JVM nodes exec on simple-computer on physical network=Ethernet, ..., Ln
view=some legacy big data appliance).  In this scenario I would probably
want to be able to segregate/configure/operate my ISPN L1 local data view
(near cache) ---of---> ISPN L2 remoteCache data view ('real' cache
custodian) in ways that are different than a grid deployed onto a typical
homogeneous set of resources.

Again, we likely agree to disagree (and that is OK, of course).

But, to extend these historically significant specific L1-capability
concepts to a potetnial  ISPN L1-capability is "Bingo!" in our opinion. 
Now, It might not be an urgent priority to do ASAP, and it will expose
complexity, but it is a fantastic ambition to consider.







--
View this message in context: http://infinispan-developer-list.980875.n3.nabble.com/infinispan-dev-L1-Data-Container-tp4027447p4027466.html
Sent from the Infinispan Developer List mailing list archive at Nabble.com.