I'm sure this is discussed on a thread if someone wants to search. :)
I'm lazy so I'll just guess about the reason. Going through the
interceptor chain adds all sorts of possibly unwanted side effects; e.g.
creation of in-memory nodes cause writes to persistent store,
replication, gravitation, etc. Many can be eliminated by setting
options, but thinking through all the ways it can break will take a lot
of work and it will inherently be fragile.
Manik's right though; my question was about the Node Modified bit. :)
Vladimir Blagojevic wrote:
There was a reason we did not go through interceptor chain; I
remember
it well; but what it was - kill me - I cannot recall.
Brian Stansberry wrote:
> State transfer doesn't go through the interceptor chain when it
> creates nodes; it just builds up a tree. IIRC we decided to
> specifically code in a Node Created notification; perhaps we just
> didn't think about Node Modified? Vladimir, your memory any better?
>
> Manik Surtani wrote:
>> Not sure if this is a feature or a bug. Brian/Vladimir, do you
>> recall whether Node Modified notifications were specifically
>> suppressed during state transfer, and if so, why?
>>
>> Cheers
>> Manik
>>
>> Begin forwarded message:
>>
>>> From: aditsu <do-not-reply(a)jboss.com>
>>> Date: 13 November 2007 09:14:11 GMT
>>> To: manik.surtani(a)jboss.com
>>> Subject: [JBossCache] - Replication and notifications
>>>
>>> Hi, I'm using JBC 2.0.0.GA (core)
>>> I set up 2 caches with REPL_SYNC and memory state fetching, and I
>>> added a listener to the 2nd cache before starting it.
>>> It looks like when fetching the memory state, the cache only fires
>>> NODE_CREATED notifications, which contain no data. However, when I
>>> put a new node afterwards, in either cache instance, I get a
>>> NODE_CREATED followed by a NODE_MODIFIED with the node data map.
>>> Is there a way to get the data while it is being fetched from a
>>> replicated cache?
>>>
>>> Thanks
>>> Adrian
>>>
>>> View the original post :
>>>
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4103974#...
>>>
>>>
>>> Reply to the post :
>>>
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...
>>>
>>
>> --
>> Manik Surtani
>> Lead, JBoss Cache
>> manik(a)jboss.org
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com