JBCACHE-388 Provide modified data in callbacks
by Ben Wang
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
18 years, 1 month
RE: [jbosscache-dev] Consistent factory method
by Brian Stansberry
I prefer both ;-) Perhaps add a class to o.j.c.factories that creates a
singleton DefaultCacheFactory and exposes static methods? If people
don't want to use it, that's fine, but it's there for the 99.9% use
case. An issue is what to name it.
Static is a bit easier to understand when using the MC as it eliminates
an extra bean instantiation.
Static:
<bean name="MyCacheConfig" class="org.jboss.cache.config.Configuration">
....
</bean>
<bean name="MyCache">
<constructor factoryClass="org.jboss.cache.pojo.PojoCacheFactory"
factoryMethod="createInstance">
<parameter class="org.jboss.cache.config.Configuration"><inject
bean="MyCacheConfig"/></parameter>
<parameter>false</parameter>
</constructor>
</bean>
Instance:
<bean name="MyCacheConfig" class="org.jboss.cache.config.Configuration">
....
</bean>
<bean name="MyCacheFactory"
class="org.jboss.cache.factories.DefaultCacheFactory"/>
<bean name="MyCache">
<constructor factoryMethod="createCache">
<factory bean="MyCacheFactory"/>
<parameter class="org.jboss.cache.config.Configuration"><inject
bean="MyCacheConfig"/></parameter>
<parameter>false</parameter>
</constructor>
</bean>
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> Ic. So what do other people prefer, if we can do it either way?
>
> -----Original Message-----
> From: Manik Surtani [mailto:msurtani@redhat.com]
> Sent: Thursday, October 26, 2006 9:17 PM
> To: Ben Wang
> Cc: jbosscache-dev(a)lists.jboss.org
> Subject: Re: [jbosscache-dev] Consistent factory method
>
> Nothing more than the factory is a simple class. If user
> code wants to wrap it in a singleton and create factory
> methods in the wrapper, it is up to them. Just keeping things simple.
>
>
>> Manik,
>>
>> This is a minor issue raised by Brian when he is constructing the
>> bean file for AS5. Currently, we have slight way of creating a cache
>> instance from the factory method.
>>
>> In Cache, we do:
>>
>> CacheFactory factory = new DefaultCacheFactory();
>> CacheSPI tree = (CacheSPI) factory.createCache(c, false);
>>
>> While in PojoCache, we do:
>> cache_ = PojoCacheFactory.createInstance(configFile, false);
>>
>> Nothing wrong with both approaches but maybe we should be consistent
>> in both cache instances. And I don't mind to switch if needed. For
>> me, the reason that I did it in the first place is I don't forsee a
>> pluggable cache instance for PojoCache. And if needed, another
>> Factory can be used as well.
>>
>> I thought originally with your approach, there is more control over
>> the lifecycle methods. But now it is probably not needed there. Any
>> other reason to stick with your approach?
>>
>> Thanks,
>>
>> -Ben
18 years, 1 month
Re: Minutes from JBossCache and Hibernate conf call.
by Manik Surtani
On 27 Oct 2006, at 16:36, Owen Taylor wrote:
> On Fri, 2006-10-27 at 15:40 +0100, Manik Surtani wrote:
>> First off, thanks to all who attended, it was a very useful session.
>> Please let me know if I have missed anything or if there are any
>> inaccuracies.
>
>> 1) Detail of Hibernate usage of JBoss Cache
>>
>> - Notion mismatch between a Cache put() - which is a write - and a
>> Hibernate put() - which is a read from a DB. A Hibernate update() is
>> effectively a write.
>> - This notion mismatch causes unnecessary locking in JBoss Cache
>> when doing a Cache put().
>> - Hibernate maintains 3 types of caches: for caching entities,
>> caching queries and caching collections
>> - Most other cache providers used are flat and non-replicated,
>> assumes each region is isolated
>> - Replicated EHCache not tested with Hibernate.
>> - Assumes other cache providers don't handle concurrency, Hibernate
>> wraps these in a ConcurrencyStrategy and handles locking separately.
>> - Hence to need to differentiate between a Hibernate put() and
>> update() as these both translate to a cache.put().
>> - JBoss Cache could be used this way, with IsolationLevel.NONE
>> - This is a waste though, as it prevents using JBoss Cache to it's
>> full potential.
>> - A good temp. solution for now.
>
> One thing I mentioned on the call is that ReadWriteStrategy
> requires not
> just a distributed store for objects, but also distributed locking.
> It needs functions to synchronously lock/unlock a node across the
> cluster - a concept which is pretty alien to the current JBoss Cache
> code. (?)
>
> - Owen
>
>
True, that is a good point. And thinking of hacking that in, it
would actually make more sense to implement a proper
putForExternalRead() solution.
--
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, 1 month
RE: [jbosscache-dev] 1.4.0.SP2 or 1.4.1?
by Vladimir Blagojevic
No testing yet. We are about to test jbc head for regression problems in
2.4. We can include jbc 1.4 branch in the same process. I am not sure
how mux based testing is done in jbc 1.4 branch. Brian might be familiar
with this?
> -----Original Message-----
> From: jbosscache-dev-bounces(a)lists.jboss.org
> [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Bela Ban
> Sent: Friday, October 27, 2006 7:51 AM
> To: Manik Surtani
> Cc: jbosscache-dev(a)lists.jboss.org
> Subject: Re: [jbosscache-dev] 1.4.0.SP2 or 1.4.1?
>
> Has any testing been done on 812 ? Vlad ?
> Yes, I think this warrents another version number, not just an SP
18 years, 1 month
RE: [jbosscache-dev] Consistent factory method
by Ben Wang
Ic. So what do other people prefer, if we can do it either way?
-----Original Message-----
From: Manik Surtani [mailto:msurtani@redhat.com]
Sent: Thursday, October 26, 2006 9:17 PM
To: Ben Wang
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] Consistent factory method
Nothing more than the factory is a simple class. If user code wants to wrap it in a singleton and create factory methods in the wrapper, it is up to them. Just keeping things simple.
--
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 26 Oct 2006, at 10:12, Ben Wang wrote:
> Manik,
>
> This is a minor issue raised by Brian when he is constructing the bean
> file for AS5. Currently, we have slight way of creating a cache
> instance from the factory method.
>
> In Cache, we do:
>
> CacheFactory factory = new DefaultCacheFactory();
> CacheSPI tree = (CacheSPI) factory.createCache(c, false);
>
> While in PojoCache, we do:
> cache_ = PojoCacheFactory.createInstance(configFile, false);
>
> Nothing wrong with both approaches but maybe we should be consistent
> in both cache instances. And I don't mind to switch if needed. For me,
> the reason that I did it in the first place is I don't forsee a
> pluggable cache instance for PojoCache. And if needed, another Factory
> can be used as well.
>
> I thought originally with your approach, there is more control over
> the lifecycle methods. But now it is probably not needed there. Any
> other reason to stick with your approach?
>
> Thanks,
>
> -Ben
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
18 years, 1 month
Minutes from JBossCache and Hibernate conf call.
by Manik Surtani
First off, thanks to all who attended, it was a very useful session.
Please let me know if I have missed anything or if there are any
inaccuracies.
Cheers,
Manik
1) Detail of Hibernate usage of JBoss Cache
- Notion mismatch between a Cache put() - which is a write - and a
Hibernate put() - which is a read from a DB. A Hibernate update() is
effectively a write.
- This notion mismatch causes unnecessary locking in JBoss Cache
when doing a Cache put().
- Hibernate maintains 3 types of caches: for caching entities,
caching queries and caching collections
- Most other cache providers used are flat and non-replicated,
assumes each region is isolated
- Replicated EHCache not tested with Hibernate.
- Assumes other cache providers don't handle concurrency, Hibernate
wraps these in a ConcurrencyStrategy and handles locking separately.
- Hence to need to differentiate between a Hibernate put() and
update() as these both translate to a cache.put().
- JBoss Cache could be used this way, with IsolationLevel.NONE
- This is a waste though, as it prevents using JBoss Cache to it's
full potential.
- A good temp. solution for now.
2) Use of a putForExternalRead():
- Successor to the deprecated putFailFast() and Options.FAIL_SILENTLY
- TX suspension
- Minimal error messages and exceptions
- Consider Owen's solution to only write if the node does not exist
- otherwise fail silently.
- Steve and Manik to investigate the correctness of this approach.
- Deprecate/remove Option.FAIL_SILENTLY && putFailFast()
- Could be introduced in JBoss Cache 1.5.0 && 2.0.0?
3) Optimistic locking and data versioning issues with the Query Cache
- Invalidation and data versioning does not make sense for Query
Cache and Collections Cache
- Data needs to be available on all cluster instances
- Versions only exist for entities, not for queries.
- Solution: Run multiple caches on a multiplexed JGroups channel.
- Each cache instance configured differently to meet the needs of
caching queries, collections or entities.
- Hack this into Hibernate 3.2.x TreeCacheProvider
_ Better architectural abstractions between the different caches in
3.3.x?
4) Invalidation issues and edge cases (JBCACHE-806)
- Description: V2 put into CacheA. CacheB has V1, gets the
invalidation msg, and V1 is evicted. Someone now calls a put() on
CacheB with V1, and you are afraid this will be written into the
cache? This is true, the invalidation back to CacheA will fail, but
CacheB will have stale data in the cache.
- Solution: Use INV_SYNC and if a remote eviction fails with a data
version mismatch on a remote node, propagate the exception back to
the caller.
- JBCACHE-806, target for 1.4.x series.
*** Actions
* Put unit tests to cover these new features in JBoss Cache (MS)
* Put together comprehensive integration tests to exercise these,
try and get these tests into automated release testing with QA for
JBoss Cache and Hibernate (SE)
* Investigate JBoss Cache in IsolationLevel.NONE with ReadWrite
Concurrency Strategy (SE)
* Investigate putForExternalRead() (MS)
* Investigate multiplexed JBoss Caches in TreeCacheProvider (SE)
* Fix JBCACHE-806 (MS)
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, 1 month
RE: Beta Release for AS 5
by Ben Wang
I should be ready. There are still remote notification piece that I want to do but it can wait after alpha.
-Ben
________________________________
From: Manik Surtani [mailto:manik@jboss.org]
Sent: Friday, October 27, 2006 6:31 PM
To: Ben Wang
Cc: Bela Ban; Brian Stansberry; Vladimir Blagojevic; jbosscache-dev(a)lists.jboss.org
Subject: Re: Beta Release for AS 5
I agree, we too would have > 1 beta.
TBH, I'm ready for an Alpha for pretty early next week, how about the rest of you guys?
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 27 Oct 2006, at 02:20, Ben Wang wrote:
Looks like AS will have beta1 and beta2 releases, so I am wondering if we can follow the same here? :-) Given that the alpha won't be out untill next week, my concern is a real "beta" by 11/15 will be a bit too short given this is a major release.
________________________________
From: Bela Ban
Sent: Friday, October 27, 2006 4:29 AM
To: Brian Stansberry
Cc: Manik Surtani; Ben Wang; Vladimir Blagojevic
Subject: Re: FW: Beta Release for AS 5
+1 from me, but Manik's the one to decide really...
Brian Stansberry wrote:
Do you guys see any problem having a 2.0.0.Beta available by say 11/15 or so? It would just need to support the existing AS use cases; i.e. anything extra we want for 2.0.0.GA doesn't need to be in it.
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
________________________________
From: Andy Miller
Sent: Tuesday, October 24, 2006 7:37 PM
To: Scott M Stark; Anil Saldhana; Thomas Diesler; Jason T. Greene; Carlo de Wolf; Bill Burke; Adrian Brock; Brian Stansberry
Subject: Beta Release for AS 5
Guys,
Based on my earlier thread to gather input for a Beta release of AS 5 we arrived at a hard date of December 8th. That Beta would have the basics working, but not be the final design of the MC/Deployer stuff, and the profile service would not have the management API defined and implemented. We will follow with a second Beta which will clean-up everything, incorporate any refactoring necessary, and add the management API for JBoss ON to the profile service.
Since then, there has been some additional discussion about can we release something by JBoss World, which as you know, is November 20th.
So here's the challenge. Release an AS 5 that has deployers on the new MC that work, has decent TCK coverage for EJB 3 and WS working, and has the JGroups/JBoss Cache releases integrated, all from HEAD by November 20th.
Let's accept this challenge, and if you guys can pull it off, I'll find a way to reward each of you for the effort.
Thanks.
Andrig (Andy) Miller
VP, Engineering
JBoss, a division of Red Hat
--
Bela Ban
Lead JGroups / Manager JBoss Clustering Group
JBoss - a division of Red Hat
18 years, 1 month
RE: Beta Release for AS 5
by Brian Stansberry
I should finish up the eviction config stuff today; at least to an
extent acceptable for an alpha. Need to write more tests of edge cases,
but that shouldn't hold up an alpha. So early next week sounds good.
________________________________
From: Manik Surtani [mailto:manik@jboss.org]
Sent: Friday, October 27, 2006 5:31 AM
To: Ben Wang
Cc: Bela Ban; Brian Stansberry; Vladimir Blagojevic;
jbosscache-dev(a)lists.jboss.org
Subject: Re: Beta Release for AS 5
I agree, we too would have > 1 beta.
TBH, I'm ready for an Alpha for pretty early next week, how
about the rest of you guys?
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, 1 month
RE: Thoughts on JBCACHE-794?
by Ben Wang
I think the forum is fine as is (that is the reason I didn't add anything to it earlier).
-----Original Message-----
From: Manik Surtani [mailto:manik@jboss.org]
Sent: Friday, October 27, 2006 8:36 PM
To: Ben Wang
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: Thoughts on JBCACHE-794?
Could you pls update the forum accordingly.
Thanks,
--
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 27 Oct 2006, at 12:57, Ben Wang wrote:
> Please go ahead. I don't see any adverse effect so far.
>
> Thanks,
>
> -Ben
>
> -----Original Message-----
> From: Manik Surtani [mailto:manik@jboss.org]
> Sent: Friday, October 27, 2006 7:27 PM
> To: Ben Wang
> Cc: jbosscache-dev(a)lists.jboss.org
> Subject: Thoughts on JBCACHE-794?
>
> Hey Ben,
>
> Any thoughts on this issue?
>
> http://jboss.org/index.html?module=bb&op=viewtopic&p=3979697
>
> Do you (or anyone else) see any adverse effects that could arise by
> setting the lock acquisition timeout on the eviction thread to 0?
> It would remove the chance of this deadlock occuring, plus improve
> performance in general as evictions will happen in a more timely
> fashion.
>
> 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, 1 month
RE: [jbosscache-dev] JBCACHE-710
by Ben Wang
Bummer! This is 3 months old and I'd say my memory has faded a bit. :-( And it is not easy to reproduce as well unless there is a way to screw up the FCL .dat file. I remember loader.remove() somehow doesn't throw an exception there and therefore the code moves on to notifyActivate and trigger the recursive loop.
Since now that we have documented the FCL limitation, maybe we can downgrade the serverity and push it back to later releases. This is a bug associated mostly with FLC. If I run into that problem again, I will raise it up.
Thanks,
-Ben
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Manik Surtani
Sent: Friday, October 27, 2006 6:56 PM
To: jbosscache-dev(a)lists.jboss.org
Subject: [jbosscache-dev] JBCACHE-710
Ben,
Trying to understand the problem here, assuming an AS restart leaves the FCL .dat file in an inconsistent state, wouldn't the loader.remove
() throw an exception anyway? And this would propagate up, since the
remove() method in the ActivationInterceptor does throw an Exception ...
--
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, 1 month
