July 2007 - jbosscache-dev - Jboss List Archives

jboss-cache build.1127 Build Successful

by jboss-qa-internal＠redhat.com

17 years

1
0
0 / 0

jboss-cache-testsuite-jdk16 Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

17 years

1
0
0 / 0

jboss-cache-testsuite-140 Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

17 years

1
0
0 / 0

jboss-cache-testsuite Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

17 years

1
0
0 / 0

Re: Helping out with JBCACHE-991 (Non-tx batching)

by Manik Surtani

On 31 Jul 2007, at 01:46, Vincent Marquez wrote: > Well, would using the BMTM hold write-locks until a commit? One > of the reasons I liked your proposal for having batch functionality > seperate from Tx's was the idea that you could use pessimistic > locking during a tx, and still have a way to batch calls without > locks. This may not be a common use case though. I'd have thought batching would hold locks as well. Unless you see batching as just queueing calls and applying them when batchComplete() (or whatever we call it) is invoked. But then how do you deal with failures? Is the batch atomic? > > I realize this won't be an issue once the new MVCC locking > changes are completed, but that seemed to be quite a ways out. Not really; depends on how you logically see the function of batching. It may still make sense in MVCC as well. And hopefully it won't be that long a way out - I'm hoping by pretty early next year. I presume you've seen the designs up on the wiki? -- Manik Surtani Lead, JBoss Cache JBoss, a division of Red Hat

17 years

1
0
0 / 0

Re: Helping out with JBCACHE-991 (Non-tx batching)

by Manik Surtani

Hi Vincent Thanks for offering to do this, we're more than happy with non- committers submitting patches for features. The question is, do we implement this in the manner you specified or do we go with making the BatchModeTransactionManager production-grade and make this the default mechanism for batching calls, since most of the atomic/transactional functionality is already there. I believe the big issue with the BMTM approach is that it is based on the DummyTransactionManager which may make mixing BMTM with another transaction manager tricky (e.g., your cache uses JBossTS for most of it's operations, but you want batching as well). Perhaps one solution would be to re-write BMTM such that rather than using the DTM code, it could delegate to whichever TM you have configured. The other question is, how do batches behave within an ongoing transaction? Do they suspend existing txs and work outside of it? Or do they participate? And if so, how can this be achieved with the BMTM approach given that an existing transaction may already be running? I'm cc'ing jbosscache-dev, I expect Brian will have something to say about this. Cheers, Manik On 28 Jul 2007, at 04:48, Vincent Marquez wrote: > > Regarding http://jira.jboss.com/jira/browse/JBCACHE-991 (non Tx > batching), the application I work on has a similar need to this > and it looks like something I may be able to help out with if I > understand the requirements correctly. > > Assuming you decide to go with an API addition and add startBatch > (), commitBatch(), rollbackBatch(), etc. it appears fairly > straightforward. > > This feature seems doable by adding a BatchInterceptor to sit right > after the InvocationContextInterceptor. Using a ThreadLocal > variable, we could just buffer the invocation's MethodCall if the > current thread and cache was inside a 'batch'. CommitBatch could > simply fire off a new MethodCall "_commitBatch" that would signal > that BatchInterceptor to iterate through the list of batched > MethodCalls and re-send them down the interceptor chain. We could > do this by making cacheimpl.invokeMethod accessible from > BatchInterceptor. Rollback would work in the same way. If the > batching is not thread specific, substitute ThreadLocal with a > normal variable to hold the batched MethodCalls for similar > functionality. > > If the batch operations need to be Atomic, it would be a little > more complicated, as we'd need some sort of two phase commit > mechanism similar to the way transactions work now, except without > the node locks I'd assume. If this sounds correct and you're ok > with a non-commiter working with this part of the code, I'd be > happy to submit a patch. Otherwise, I'm happy to help out by > continuing to test and submit bugs and bug-fixes to you and Jason. > > --Vincent > > > -- Manik Surtani Lead, JBoss Cache JBoss, a division of Red Hat

17 years

1
0
0 / 0

Moving to Subversion

by Manik Surtani

This has been on the roadmap [1] post-2.0.0, and I will be looking at making the migration across as soon as I tag 2.0.0.GA. This will mean the repository will be frozen for a couple of days, I'll have a more detailed picture once I hear back from IT on this. In the meanwhile, Jason and I spoke about the src tree structure and breaking this up so we can do independent pojo and core cache releases. Please see the JBoss Cache Development wiki [2] for details, particularly the section titled " SVN (beyond 2.0.0.GA) ". This also covers using maven for the builds rather than ant. Feedback is always appreciated! Cheers, Manik [1] http://jira.jboss.com/jira/browse/JBCACHE-1142 [2] http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheDevelopment -- Manik Surtani Lead, JBoss Cache JBoss, a division of Red Hat

17 years

2
1
0 / 0

jboss-cache build.1126 Build Successful

by jboss-qa-internal＠redhat.com

17 years

1
0
0 / 0

jboss-cache-testsuite-jdk16 Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

17 years

1
0
0 / 0

JBoss Cache 1.4.1.SP4 released

by Manik Surtani

FYI, this has now been released. JBoss.org's blog site is still screwy so see here for details: http://jbosscache.blogspot.com Cheers, -- Manik Surtani Lead, JBoss Cache JBoss, a division of Red Hat

17 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-dev July 2007