RE: [jbosscache-dev] HEAD
by Vladimir Blagojevic
I will also merge my partial state transfer changes to HEAD related to
RegionManager,Region,TreeCache.
If I had a vote I would vote to put JBC alpha/DR2 to AS5 beta instead of
this JBC beta.
> -----Original Message-----
> From: jbosscache-dev-bounces(a)lists.jboss.org
> [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of
> Manik Surtani
> Sent: Tuesday, November 14, 2006 11:32 AM
> To: Brian Stansberry
> Cc: jbosscache-dev(a)lists.jboss.org
> Subject: [jbosscache-dev] HEAD
>
> Brian,
>
> I've started work on merging the Region/RegionManagers for
> eviction.
> The interfaces and API are now in place, but it breaks in a
> few places, stuff that's still WIP.
>
> Hopefully at least you can go ahead with your integration, I
> will have it all functional by tomorrow though. And then the
> rest of tomorrow and thu to stabilise as much as I can before
> I release on Fri.
>
> Do you think we can get away with a .DR2 or Alpha instead of
> a Beta?
> Because this certainly isn't Beta quality. :-)
>
> Cheers,
> --
> Manik Surtani
>
> Lead, JBoss Cache
> JBoss, a division of Red Hat
>
> Email: manik(a)jboss.org
> Telephone: +44 7786 702 706
> MSN: manik(a)surtani.org
> Yahoo/AIM/Skype: maniksurtani
>
>
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
18 years
HEAD
by Manik Surtani
Brian,
I've started work on merging the Region/RegionManagers for eviction.
The interfaces and API are now in place, but it breaks in a few
places, stuff that's still WIP.
Hopefully at least you can go ahead with your integration, I will
have it all functional by tomorrow though. And then the rest of
tomorrow and thu to stabilise as much as I can before I release on Fri.
Do you think we can get away with a .DR2 or Alpha instead of a Beta?
Because this certainly isn't Beta quality. :-)
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
18 years
Re: optimistic opt idea
by Manik Surtani
Hmm, interesting idea, especially that 2.0.0 is baselined on Java5.
How would such objects be loaded into the cache in the first place?
Perhaps just the initial modification (creation of the object in
cache) and thereafter treated as immutable?
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
On 14 Nov 2006, at 16:06, Julien Viet wrote:
> have you ever though about having a way to tell to the optimistic
> locking that an object is immutable in order to avoid unnecessary
> copies ?
>
> like
>
> public interface Immutable { }
>
> that an object could implement as a marker interface
>
> and
>
> @Immutable
>
> that an object could be annotated with
>
>
>
> Julien Viet
> JBoss Portal Project Lead
> Red Hat Inc.
>
>
>
18 years
JBoss Cache 1.4.1.BETA released
by Manik Surtani
Read all about it here:
http://labs.jboss.com/portal/index.html?
ctrl:cmd=render&ctrl:window=default.blog.PrjBlogPortletWindowDefaultBlog
&project=jbosscache&from=1&link=JBoss_Cache_1.4.1.BETA_released#JBoss_Ca
che_1.4.1.BETA_released
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
18 years
RE: [jbosscache-dev] Build failure with J2SE 1.4.2_13
by Brian Stansberry
It produces a 1.4 compatible binary (jboss-cache.jar), but JDK 5 is
needed to build. It also produces a binary jboss-cache-jdk50.jar that
requires JDK 5 at runtime. The two jars are identical except the latter
has a few annotation classes included.
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> You need JDK 5
>
> Pavel Tsekov wrote:
>> Hello,
>>
>> Trying to build JBossCache from the Branch_JBossCache_1_4_0 branch
>> with J2SE 1.4.2_13 I get the failures listed below. Is there a cure
>> for this issue ?
>>
>> Thanks!
>>
>> compile-classes14:
>> [mkdir] Created dir: E:\src\JBossCache\output\classes
>> [mkdir] Created dir: E:\src\JBossCache\output\test-classes
>> [mkdir] Created dir: E:\src\JBossCache\output\varia-classes
>> [javac] Compiling 262 source files to
> E:\src\JBossCache\output\classes
>> [javac] Note: Some input files use or override a deprecated API.
>> [javac] Note: Recompile with -deprecation for details.
>> [javac] Compiling 3 source files to
> E:\src\JBossCache\output\varia-classes
>> [javac] Compiling 363 source files to
> E:\src\JBossCache\output\test-classes
>> [javac]
> E:\src\JBossCache\tests\stress\org\jboss\cache\BuddyReplicatio
> nStressTest.java:18: cannot resolve symbol
>> [javac] symbol : class UUID
>> [javac] location: package util
>> [javac] import java.util.UUID;
>> [javac] ^
>> [javac]
> E:\src\JBossCache\tests\functional\org\jboss\cache\marshall\Tr
> eeCacheMarshallerTestBase.java:141: cannot resolve symbol
>> [javac] symbol : class StringBuilder
>> [javac] location: class
> org.jboss.cache.marshall.TreeCacheMarshallerTestBase
>> [javac] StringBuilder sb = new StringBuilder();
>> [javac] ^ [javac]
> E:\src\JBossCache\tests\functional\org\jboss\cache\marshall\Tr
> eeCacheMarshallerTestBase.java:141: cannot resolve symbol
>> [javac] symbol : class StringBuilder
>> [javac] location: class
> org.jboss.cache.marshall.TreeCacheMarshallerTestBase
>> [javac] StringBuilder sb = new StringBuilder();
>> [javac] ^
>> [javac]
> E:\src\JBossCache\tests\functional\org\jboss\cache\marshall\Tr
> eeCacheMarshallerTestBase.java:157: cannot resolve symbol
>> [javac] symbol : class StringBuilder
>> [javac] location: class
> org.jboss.cache.marshall.TreeCacheMarshallerTestBase
>> [javac] StringBuilder sb = new StringBuilder();
>> [javac] ^ [javac]
> E:\src\JBossCache\tests\functional\org\jboss\cache\marshall\Tr
> eeCacheMarshallerTestBase.java:157: cannot resolve symbol
>> [javac] symbol : class StringBuilder
>> [javac] location: class
> org.jboss.cache.marshall.TreeCacheMarshallerTestBase
>> [javac] StringBuilder sb = new StringBuilder();
>> [javac] ^
>> [javac]
> E:\src\JBossCache\tests\functional\org\jboss\cache\marshall\Tr
> eeCacheMarshallerTestBase.java:173: cannot resolve symbol
>> [javac] symbol : class StringBuilder
>> [javac] location: class
> org.jboss.cache.marshall.TreeCacheMarshallerTestBase
>> [javac] StringBuilder sb = new StringBuilder();
>> [javac] ^ [javac]
> E:\src\JBossCache\tests\functional\org\jboss\cache\marshall\Tr
> eeCacheMarshallerTestBase.java:173: cannot resolve symbol
>> [javac] symbol : class StringBuilder
>> [javac] location: class
> org.jboss.cache.marshall.TreeCacheMarshallerTestBase
>> [javac] StringBuilder sb = new StringBuilder();
>> [javac] ^
>> [javac]
> E:\src\JBossCache\tests\stress\org\jboss\cache\BuddyReplicatio
> nStressTest.java:113: cannot resolve symbol
>> [javac] symbol : variable UUID
>> [javac] location: class
> org.jboss.cache.BuddyReplicationStressTest.LoadBalancer
>> [javac] return UUID.randomUUID().toString();
>> [javac] ^ [javac] Note: Some input files use or
>> override a deprecated API. [javac] Note: Recompile with
>> -deprecation for details. [javac] 8 errors
>>
>> BUILD FAILED
>>
>> _______________________________________________
>> 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
Ph: 510-396-3864
skype: bstansberry
IT executives: Red Hat still #1 for value
http://www.redhat.com/promo/vendor/
18 years
Build failure with J2SE 1.4.2_13
by Pavel Tsekov
Hello,
Trying to build JBossCache from the Branch_JBossCache_1_4_0 branch
with J2SE 1.4.2_13 I get the failures listed below. Is there a cure
for this issue ?
Thanks!
compile-classes14:
[mkdir] Created dir: E:\src\JBossCache\output\classes
[mkdir] Created dir: E:\src\JBossCache\output\test-classes
[mkdir] Created dir: E:\src\JBossCache\output\varia-classes
[javac] Compiling 262 source files to E:\src\JBossCache\output\classes
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -deprecation for details.
[javac] Compiling 3 source files to E:\src\JBossCache\output\varia-classes
[javac] Compiling 363 source files to E:\src\JBossCache\output\test-classes
[javac] E:\src\JBossCache\tests\stress\org\jboss\cache\BuddyReplicationStressTest.java:18: cannot resolve symbol
[javac] symbol : class UUID
[javac] location: package util
[javac] import java.util.UUID;
[javac] ^
[javac] E:\src\JBossCache\tests\functional\org\jboss\cache\marshall\TreeCacheMarshallerTestBase.java:141: cannot resolve symbol
[javac] symbol : class StringBuilder
[javac] location: class org.jboss.cache.marshall.TreeCacheMarshallerTestBase
[javac] StringBuilder sb = new StringBuilder();
[javac] ^
[javac] E:\src\JBossCache\tests\functional\org\jboss\cache\marshall\TreeCacheMarshallerTestBase.java:141: cannot resolve symbol
[javac] symbol : class StringBuilder
[javac] location: class org.jboss.cache.marshall.TreeCacheMarshallerTestBase
[javac] StringBuilder sb = new StringBuilder();
[javac] ^
[javac] E:\src\JBossCache\tests\functional\org\jboss\cache\marshall\TreeCacheMarshallerTestBase.java:157: cannot resolve symbol
[javac] symbol : class StringBuilder
[javac] location: class org.jboss.cache.marshall.TreeCacheMarshallerTestBase
[javac] StringBuilder sb = new StringBuilder();
[javac] ^
[javac] E:\src\JBossCache\tests\functional\org\jboss\cache\marshall\TreeCacheMarshallerTestBase.java:157: cannot resolve symbol
[javac] symbol : class StringBuilder
[javac] location: class org.jboss.cache.marshall.TreeCacheMarshallerTestBase
[javac] StringBuilder sb = new StringBuilder();
[javac] ^
[javac] E:\src\JBossCache\tests\functional\org\jboss\cache\marshall\TreeCacheMarshallerTestBase.java:173: cannot resolve symbol
[javac] symbol : class StringBuilder
[javac] location: class org.jboss.cache.marshall.TreeCacheMarshallerTestBase
[javac] StringBuilder sb = new StringBuilder();
[javac] ^
[javac] E:\src\JBossCache\tests\functional\org\jboss\cache\marshall\TreeCacheMarshallerTestBase.java:173: cannot resolve symbol
[javac] symbol : class StringBuilder
[javac] location: class org.jboss.cache.marshall.TreeCacheMarshallerTestBase
[javac] StringBuilder sb = new StringBuilder();
[javac] ^
[javac] E:\src\JBossCache\tests\stress\org\jboss\cache\BuddyReplicationStressTest.java:113: cannot resolve symbol
[javac] symbol : variable UUID
[javac] location: class org.jboss.cache.BuddyReplicationStressTest.LoadBalancer
[javac] return UUID.randomUUID().toString();
[javac] ^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -deprecation for details.
[javac] 8 errors
BUILD FAILED
18 years
RE: [jbosscache-dev] FW: 1.4 aop test failures
by Brian Stansberry
This looks fine, Ben.
Vladimir, could you be sure this gets in 2.0.0.Beta1?
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> Thanks for looking into this Ben. Do you need to apply this to HEAD
> as well?
>
>> (Don't know if this has impact on other parts of the code, so FYI
>> here.)
>>
>> I have pinpointed (at least part of) the problem to
>> TreeCache.loadState() where now instead of sending the exception in
>> rsp (response), we now throw it directly from TreeCache. Therefore,
>> we didn't catch the TimeoutException and re-try the state transfer
>> part.
>>
>> I have created a Jira for this
>> (http://jira.jboss.com/jira/browse/JBCACHE-844). Brian, I have
>> checked in my fix, if you can please review it, that will be great!
>>
>> Thanks,
>>
>> -Ben
>>
>> -----Original Message-----
>> From: Brian Stansberry
>> Sent: Monday, November 13, 2006 12:43 AM
>> To: Ben Wang; 'Manik Surtani'; Vladimir Blagojevic
>> Subject: RE: 1.4 aop test failures
>>
>> Manik asked me a similar question a couple days ago about some BR
>> state transfer tests that were failing. I didn't know. But it looks
>> like those tests are passing now; perhaps whatever he figured out
>> will work for the aop ones as well.
>>
>> I was trying to look at the post- 11/01/06 jbosscache-testsuite-140
>> cc reports to get a clue as to what changed, but it looks like those
>> reports are showing commits on HEAD rather than
>> Branch_JBossCache_1_4_0.
>> :(
>>
>> Ben Wang wrote:
>>> Guys,
>>>
>>> There are couple of test failure in 1.4 branch for aop.statetransfer
>>> that I am trying to to pin down. As far as I can see from
>>> CruiseControl, 11/01/06 build still passed.
>>> But then statetransfer part failed for cache and cache.aop as well.
>>> Do
>>
>>> you guys have any clue why it failed? Maybe it can help me to fix
>>> the failure before I dig it deeper.
>>>
>>> Thanks a lot,
>>>
>>> -Ben
>>
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
> _______________________________________________
> 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
Ph: 510-396-3864
skype: bstansberry
IT executives: Red Hat still #1 for value
http://www.redhat.com/promo/vendor/
18 years
Expose getLocalAddress and getMembers in Cache
by Brian Stansberry
Methods getLocalAddress and getMembers were in the public API of
TreeCache but now you need to cast to CacheSPI to get access to them.
Can we move them back to Cache? I've seen references to both on forums
and support cases, so I think they are used. Clustered SSO uses
getLocalAddress() -- I worked around it by using CacheSPI, but would
prefer not doing that.
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
IT executives: Red Hat still #1 for value
http://www.redhat.com/promo/vendor/
18 years
FW: 1.4 aop test failures
by Ben Wang
(Don't know if this has impact on other parts of the code, so FYI here.)
I have pinpointed (at least part of) the problem to
TreeCache.loadState() where now instead of sending the exception in rsp
(response), we now throw it directly from TreeCache. Therefore, we
didn't catch the TimeoutException and re-try the state transfer part.
I have created a Jira for this
(http://jira.jboss.com/jira/browse/JBCACHE-844). Brian, I have checked
in my fix, if you can please review it, that will be great!
Thanks,
-Ben
-----Original Message-----
From: Brian Stansberry
Sent: Monday, November 13, 2006 12:43 AM
To: Ben Wang; 'Manik Surtani'; Vladimir Blagojevic
Subject: RE: 1.4 aop test failures
Manik asked me a similar question a couple days ago about some BR state
transfer tests that were failing. I didn't know. But it looks like
those tests are passing now; perhaps whatever he figured out will work
for the aop ones as well.
I was trying to look at the post- 11/01/06 jbosscache-testsuite-140 cc
reports to get a clue as to what changed, but it looks like those
reports are showing commits on HEAD rather than Branch_JBossCache_1_4_0.
:(
Ben Wang wrote:
> Guys,
>
> There are couple of test failure in 1.4 branch for aop.statetransfer
> that I am trying to to pin down. As far as I can see from
> CruiseControl, 11/01/06 build still passed.
> But then statetransfer part failed for cache and cache.aop as well. Do
> you guys have any clue why it failed? Maybe it can help me to fix the
> failure before I dig it deeper.
>
> Thanks a lot,
>
> -Ben
18 years
RE: [jbosscache-dev] JBCACHE-388 Provide modified data incallbacks
by Brian Stansberry
Cool. One other small thing: for completeness the MapModifications
struct should probably also have a "public Map unmodifiedEntries" field.
Manik Surtani wrote:
> Ok, sounds cool, will add this to the JIRA task.
>
>> How about a variation on Ben's idea of providing an enum to specify
>> the type of change? Sample API follows.
>>
>> /**
>> * Called before and after a {@link Node} is modified. Data passed
>> in the
>> * <code>modData</code> param can be used to determine what was
>> modified.
>> * <p/>
>> * When called with <code>pre == true</code>, <code>modData</code>
>> is the
>> * initial state of the {@link Node} before modification.
>> * <p/>
>> * When called with <code>pre == false</code>, the contents of
>> <code>modData</code>
>> * depend on the value of <code>modTtype</code>:
>> * <ul>
>> * <li><b>PUT_KEY_VALUE</b>: Map contains the single key/value pair
>> that was added.</li>
>> * <li><b>REMOVE_KEY_VALUE</b>: Map contains the single key/value
>> pair that was removed.</li>
>> * <li><b>PUT_MAP</b>: Map contains the new state of the {@link
>> Node} following modification.
>> * This map includes modified key/value pairs as well as any that
>> were not affected.</li>
>> * </ul>
>> * <p/>
>> * Implementations interested in seeing the difference in the node
>> data in the PUT_MAP case
>> * can cache the <code>modData</code> map passed when <code>pre ==
>> true</code>, and then
>> * when the <code>pre == false</code> callback is received, pass the
>> cached map and the new
>> * <code>modData</code> to {@link
>> org.jboss.cache.util.Util.diffNodeData(Map pre, Map post)}. *
>> * @param fqn Fqn of the node being modified
>> * @param pre <code>true</code> if the modification is about to
>> be applied,
>> * <code>false</code> if it has already been applied
>> * @param isLocal <code>true</code> if the modification originated
>> locally,
>> * <code>false</code> if it was replicated from
>> another node
>> * @param modType PUT_KEY_VALUE, REMOVE_KEY_VALUE or PUT_MAP
>> * @param modData Unmodifiable {@link Map}; will not be
>> <code>null</code>. See
>> * description above.
>> */
>> public void nodeModified(Fqn fqn, boolean pre, boolean isLocal,
>> ModificationType modType, Map modData);
>>
>> public class Util {
>>
>> public static MapModifications diffNodeData(Map pre, Map post) {
>> // do the diff here }
>>
>> public static class MapModifications {
>> public Map addedEntries;
>> public Map removedEntries;
>> public Map modifiedEntries;
>> }
>> }
>>
>>
>> Advantage here is JBC goes to little effort to support this, so
>> overhead is low if the listener isn't interested. CacheListener impls
>> that are interested in modifications, but where the app never calls
>> put(Fqn, Map)
>> also have very little overhead. I believe Jerry's DistributedState
>> is such a case. The big overhead of doing the diff is only incurred
>> by CacheListener impls that care, and we provide much of the code to
>> do it for them.
>>
>> - Brian
>>
>> Jerry Gauthier wrote:
>>> This issue is relevant for DistributedState in AS 5.0 where the
>>> implementation was rewritten to use TreeCache for the underlying
>>> replicated store. There's currently a mismatch between the events
>>> published by DistributedState and those offered by TreeCache.
>>> Specifically, DistributedState identifies the data key and new value
>>> for modified categories (which are TreeCache nodes); it also
>>> identifies keys that are removed. Currently it's not possible to
>>> obtain this information from TreeCache unless the subscriber
>>> responds to the "pre" and "post" modification events by retrieving
>>> the modified node's Map before/after and then performing a diff
>>> operation.
>>>
>>> I've looked at the new CacheListener interface and it looks like it
>>> helps a little since it provides the Map as part of the event. But
>>> as Ben pointed out, it's still necessary for the subscriber to diff
>>> the maps to determine what was changed. So this doesn't appear to
>>> help significantly for DistributedState as the hard part is
>>> performing the diff, not retrieving the map.
>>>
>>> Jerry
>>>
>>>
>>>>>> "Brian Stansberry" <brian.stansberry(a)jboss.com> 10/30/06 11:33 AM
>>>>>>
>>> How common is the use case where the listener wants to know the
>>> differences? I'd be concerned about the overhead of creating
>>> objects to encapsulate the diff every time there is a change --
>>> just so those objects can be passed to a CacheListener that ignores
>>> the data.
>>>
>>> OTOH, even if the current approach of just handing out the new data
>>> map is used, that should at least be a Collections.unmodifiableMap
>>> wrapping the internal data structure, so there's overhead there as
>>> well. Probably
>>> a wash, except in the put(Fqn, Map) case, where doing the diff is
>>> more tedious.
>>>
>>> I guess I have no strong opinion on this...
>>>
>>> jbosscache-dev-bounces(a)lists.jboss.org wrote:
>>>> Hmm, which approach do people prefer?
>>>>
>>>> And how would a nodeModified event from an operation like put(Fqn,
>>>> Map) be represented, since it may represent both data added as well
>>>> as data modified? I don't think this should result in multiple
>>>> callbacks.
>>>>
>>>> Cheers,
>>>>
>>>>
>>>>> Yes, I did realize that. But implementation wise, it should be
>>>>> straightforward since Cache knows exactly the identifier, right?
>>>>> We just need to add an "identifier" enum in the nodeModified
>>>>> callback. Downside is one more parameter but upside is faster
>>>>> processing such that we don't hog the calling thread.
>>>>>
>>>>> -----Original Message-----
>>>>> From: Manik Surtani [mailto:msurtani@redhat.com]
>>>>> Sent: Monday, October 30, 2006 11:15 PM
>>>>> To: Ben Wang
>>>>> Cc: jbosscache-dev(a)lists.jboss.org
>>>>> Subject: Re: [jbosscache-dev] JBCACHE-388 Provide modified data
>>>>> in callbacks
>>>>>
>>>>> Well, nodeModified covers 3 scenarios:
>>>>>
>>>>> 1) Data added to map
>>>>> 2) Data removed from map
>>>>> 3) Existing map data changed
>>>>>
>>>>> if we just passed in deltas, we'd also need to pass in keys to
>>>>> describe the operation. I.e., a nodeVisited event could pass in a
>>>>> key-value pair, but we'd also need to pass in an identifier to
>>>>> describe the modification. Which makes it pretty tedious.
>>> This is
>>>>> why I opted for just passing a snapshot of the state of data
>>>>> before and after the mod.
>>>>>
>>>>>
>>>>> --
>>>>> Manik Surtani
>>>>>
>>>>> Lead, JBoss Cache
>>>>> JBoss, a division of Red Hat
>>>>>
>>>>> Email: msurtani(a)redhat.com
>>>>> Telephone: +44 7786 702 706
>>>>> MSN: manik(a)surtani.org
>>>>> Yahoo/AIM/Skype: maniksurtani
>>>>>
>>>>>
>>>>>
>>>>> On 29 Oct 2006, at 16:20, Ben Wang wrote:
>>>>>
>>>>>> Yes, are are right. Silly me, I was looking at the pre only.
>>>>>>
>>>>>> Still, my question is that will it make more sense during post-
>>>>>> nodeModified notification to deliver only the data modified (not
>>>>>> the new data map). If I am only interested what portion of my
>>>>>> data has been modified (and I belive this is a quite common use
>>>>>> case), then I would need to keep an old data map and diff it
>>>>>> with the new data map. Doable but it would be a performance
>>>>>> killer for sure.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> -Ben
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Manik Surtani [mailto:msurtani@redhat.com]
>>>>>> Sent: Friday, October 27, 2006 11:14 PM
>>>>>> To: Ben Wang
>>>>>> Cc: jbosscache-dev(a)lists.jboss.org
>>>>>> Subject: Re: [jbosscache-dev] JBCACHE-388 Provide modified data
>>>>>> in callbacks
>>>>>>
>>>>>> Is this when pre is true or false?
>>>>>>
>>>>>> If pre is true, the data will be the old data. If pre is false,
>>>>>> it will be the new data. -- Manik Surtani
>>>>>>
>>>>>> Lead, JBoss Cache
>>>>>> JBoss, a division of Red Hat
>>>>>>
>>>>>> Email: msurtani(a)redhat.com
>>>>>> Telephone: +44 7786 702 706
>>>>>> MSN: manik(a)surtani.org
>>>>>> Yahoo/AIM/Skype: maniksurtani
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 27 Oct 2006, at 13:47, Ben Wang wrote:
>>>>>>
>>>>>>> Manik,
>>>>>>>
>>>>>>> Can you clarify the semantics for the modified callbacks?
>>>>>>> Specifically, I am looking at the test case:
>>>>>>> CacheListenerTest.testRemoveData()
>>>>>>> calling
>>>>>>> cache.remove(fqn, "key2");
>>>>>>> Still has the nodeModified() coming with the original data map.
>>>>>>> Is this the expected behavior?
>>>>>>>
>>>>>>> I am hoping to see a semantics that bundles exactly the
>>>>>>> modified data.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> -Ben
>>>
>>> _______________________________________________
>>> jbosscache-dev mailing list
>>> jbosscache-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
18 years
