Re: Rolling back transactions for state transfer
by Manik Surtani
For locally originating txs (on the sender - if the sender has locked
the tree to prepare state) this is correct. Still though, if (due to
network lag) the receiver receives the prepare() before the state,
the prepare() will lock the tree.
Are you referring to started transactions started locally on the
joiner? I don't see how this could happen anyway...
--
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 13 Sep 2006, at 13:10, Bela Ban wrote:
> Guys,
>
> if we use optimistic locking, I think we would *not* need to do
> this for locally started transactions, correct ? The workspaces
> which contain the work of the local transactions would simply be
> blocked when they try to start the 2PC (until state transfer is
> over), but we would not need to discard them.
>
> Is this correct ?
> --
> Bela Ban
> Lead JGroups / Manager JBoss Clustering Group
> JBoss - a division of Red Hat
17 years, 7 months
storeState/loadState moved to AbstractCacheLoader
by Vladimir Blagojevic
Hey,
storeState/loadState cacheloader methods have been moved up to
AbstractCacheLoader. Non-delegating cacheloaders (file,jdbc,bdbje and
jdbm) are using these methods instead of implementing their own. I've
added additional tests to ensure that all combinations of cacheloaders
are interoperable and I've tested them with both streaming and byte
based transfers.
Vladimir
17 years, 7 months
StateTransferUnderLoad...
by Manik Surtani
Fails a lot more often on the lab servers now, but is still not
consistent. Anyway, it fails at least 2 in 3 tries on the multi-cpu
boxes.
Ought to be a good starting point to test any 'solutions'.
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
17 years, 7 months
RE: [jbosscache-dev] JBoss Cache 2.0.0.ALPHA status
by Vladimir Blagojevic
Yes exactly. They have their own implementation which is totally fine.
> -----Original Message-----
> From: Brian Stansberry
> Sent: Tuesday, September 12, 2006 1:38 PM
> To: Vladimir Blagojevic; Manik Surtani
> Cc: jbosscache-dev(a)lists.jboss.org
> Subject: RE: [jbosscache-dev] JBoss Cache 2.0.0.ALPHA status
>
> If I understand the thread right, the question is about
> providing a default impl of put(Fqn, Map, boolean) instead of
> just an abstract method. That sounds fine.
>
> But for the delegating cache loaders, load/store will still
> have their own implementation that doesn't call put(Fqn, Map,
> boolean), but instead uses the prepare(GTX,
> List<Modification>) idea Bela had, yes?
17 years, 7 months
RE: [jbosscache-dev] JBoss Cache 2.0.0.ALPHA status
by Brian Stansberry
If I understand the thread right, the question is about providing a
default impl of put(Fqn, Map, boolean) instead of just an abstract
method. That sounds fine.
But for the delegating cache loaders, load/store will still have their
own implementation that doesn't call put(Fqn, Map, boolean), but instead
uses the prepare(GTX, List<Modification>) idea Bela had, yes?
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> Yeah exactly. I just sent a private email to Brian to check my sanity.
>
> Remember how we wanted to have abstract method in AbstractCacheLoader:
>
> public abstract void put(Fqn fqn, Map attributes, boolean
> erase) throws Exception;
>
> so we can move up load/store in AbstractCacheLoader. Well I
> just saw that DelegatingCacheLoader has a really good idea
> how to implement this method as a default:
>
> public void put(Fqn fqn, Map attributes, boolean erase)
> throws Exception {
> if(erase)
> removeData(fqn);
> put(fqn, attributes);
> }
>
> So why can't we have this implementation of put in
> AbstractCacheLoader as a default and if cacheloader
> implementation has a more efficient way to implement it - so be it.
>
> I have actually done this change (moved up both load/store to
> AbstractCacheLoader) and now I am making sure that all tests
> are passing. Bdbje compatibility test is passing now:). Lets
> see that all other o.j.c.loader test are passing as well.
>
> What do you think? Any flaws with this approach?
>
>
>
>
>> -----Original Message-----
>> From: Manik Surtani [mailto:manik@jboss.org]
>> Sent: Tuesday, September 12, 2006 1:15 PM
>> To: Vladimir Blagojevic
>> Cc: jbosscache-dev(a)lists.jboss.org
>> Subject: Re: [jbosscache-dev] JBoss Cache 2.0.0.ALPHA status
>>
>> Well this is just it - I don't think we *need* to do this for the
>> BdbjeCacheLoader if you're going to implement load/store state as a
>> series of get/put calls. --
>> 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
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
17 years, 7 months
RE: [jbosscache-dev] JBoss Cache 2.0.0.ALPHA status
by Vladimir Blagojevic
Yeah exactly. I just sent a private email to Brian to check my sanity.
Remember how we wanted to have abstract method in AbstractCacheLoader:
public abstract void put(Fqn fqn, Map attributes, boolean erase) throws
Exception;
so we can move up load/store in AbstractCacheLoader. Well I just saw
that DelegatingCacheLoader has a really good idea how to implement this
method as a default:
public void put(Fqn fqn, Map attributes, boolean erase) throws Exception
{
if(erase)
removeData(fqn);
put(fqn, attributes);
}
So why can't we have this implementation of put in AbstractCacheLoader
as a default and if cacheloader implementation has a more efficient way
to implement it - so be it.
I have actually done this change (moved up both load/store to
AbstractCacheLoader) and now I am making sure that all tests are
passing. Bdbje compatibility test is passing now:). Lets see that all
other o.j.c.loader test are passing as well.
What do you think? Any flaws with this approach?
> -----Original Message-----
> From: Manik Surtani [mailto:manik@jboss.org]
> Sent: Tuesday, September 12, 2006 1:15 PM
> To: Vladimir Blagojevic
> Cc: jbosscache-dev(a)lists.jboss.org
> Subject: Re: [jbosscache-dev] JBoss Cache 2.0.0.ALPHA status
>
> Well this is just it - I don't think we *need* to do this for
> the BdbjeCacheLoader if you're going to implement load/store
> state as a series of get/put calls.
> --
> 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
17 years, 7 months
Re: [jbosscache-dev] JBoss Cache 2.0.0.ALPHA status
by Manik Surtani
Well this is just it - I don't think we *need* to do this for the
BdbjeCacheLoader if you're going to implement load/store state as a
series of get/put calls.
--
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 12 Sep 2006, at 14:46, Vladimir Blagojevic wrote:
> Manik,
>
> Just a suggestion. It would be great if you can possibly have this
> done
> earlier than later so I can move up load/store methods up to
> AbstractCacheLoader and have this whole thing nice and dandy....
>
> Vladimir
>
>> -----Original Message-----
>> From: Manik Surtani [mailto:manik@jboss.org]
>> Sent: Tuesday, September 12, 2006 4:25 AM
>> To: Vladimir Blagojevic
>> Subject: Re: [jbosscache-dev] JBoss Cache 2.0.0.ALPHA status
>>
>> Never mind, found this. :-)
>>
>> --
>> Manik Surtani
>>
>> Lead, JBoss Cache
>> JBoss, a division of Red Hat
17 years, 7 months
RE: [jbosscache-dev] JBoss Cache 2.0.0.ALPHA status
by Vladimir Blagojevic
Yeah we just move them up to AbstractCacheLoader and possibly remove
them from CacheLoader interface or maybe not...
BTW, we have tests at 98.52% passing rate :)
http://cruisecontrol.jboss.com/cc/artifacts/jboss-cache-testsuite/200609
11224036/results/index.html
> -----Original Message-----
> From: Bela Ban
> Sent: Tuesday, September 12, 2006 9:38 AM
> To: Vladimir Blagojevic
> Cc: Manik Surtani; jbosscache-dev(a)lists.jboss.org
> Subject: Re: [jbosscache-dev] JBoss Cache 2.0.0.ALPHA status
>
> sorry for the confusion; that's what I meant - state transfer
> can be handled mostly by JBC, rather than the CacheLoaders.
> This would also ensure that the CL impls work with each other
>
17 years, 7 months
RE: [jbosscache-dev] JBoss Cache 2.0.0.ALPHA status
by Vladimir Blagojevic
> -----Original Message-----
> From: Manik Surtani [mailto:manik@jboss.org]
> Sent: Tuesday, September 12, 2006 4:21 AM
> To: Bela Ban
> Cc: Vladimir Blagojevic; jbosscache-dev(a)lists.jboss.org
> Subject: Re: [jbosscache-dev] JBoss Cache 2.0.0.ALPHA status
> I agree with this - but just to re-iterate, the only
> improvement here
> is formalising the format of state stored in the loaders, am
> I correct?
>
> Or is it more like removing load/store state methods on the cache
> loader interface altogether and let the interceptors deal with this
> using loader.put()/get() calls - since this is what happens
> internally (within the cloader impl) anyway?
>
I am not sure how Bela envisioned that cacheloader can be refactored to
interceptor but I suppose it is possible. What we talked about was
having
generic cacheloader storeState Method in AbstractCacheLoader. StoreState
can be generic since we simply read NodeData objects from stream and
call
put on underlying cacheloader. I suppose we can also make generic
loadState
that only relies on cacheloader's get method and a recursive call. That
would
be cool. But yes cacheloaders are getting simpler and easier to
implement :)
17 years, 7 months
RE: [jbosscache-dev] JBoss Cache 2.0.0.ALPHA status
by Ben Wang
Re: o.j.c.aop, I have fixed the build last night and one bug introducted by the cache refactoring. It should pass for 95+% now.
Re: o.j.c.pojo, integration has gone well. It probably is at 90% as well.
So I'd expect I will be ready for an Alpha release early next week given that I won't be able to work on it fully untill this coming weekend.
Cheers,
-Ben
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Manik Surtani
Sent: Tuesday, September 12, 2006 12:00 AM
To: jbosscache-dev(a)lists.jboss.org
Subject: [jbosscache-dev] JBoss Cache 2.0.0.ALPHA status
Hi guys
A quick email to talk about releasing an alpha on 2.0.0 to gather some feedback from implementors like Hibernate/Clustering/etc.
CC currently runs with a 91% success rate.
* o.j.c.buddyreplication - some failures, I'm working on this today
* o.j.c.loader - the TcpCacheLoader still has a failure around state transfer. Vladimir, what's the current feel on this, is this the load/store issue you mentioned?
* o.j.c.marshall - the large String issue, which turned out to be a bug in JBoss Serialization. Clebert's looking into fixing this and issuing a new jboss-serialization jar.
* o.j.c.statetransfer - I'm working on these today as well
* o.j.c.transaction as an intermittent failure on lab but runs fine on a local dual-core environment. I'll debug this tomorrow morning.
* o.j.c.pojo - Ben, any updates on your integrations? I understand you're on-site this week.
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
17 years, 7 months