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, 4 months
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, 4 months
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, 4 months