[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Handling cluster state when network partitions occur
by manik.surtani@jboss.com
Ok, how about:
* Provide a MergeHandler configuration
* Defaults to IgnoreOnMerge, which does nothing. FlushOnMerge also provided, which flushes in-memory state on merge
* Allows users to write their own MergeHandlers, which are basically called when a MergeView is received.
* Users could also do something similar in a CacheListener's viewChange() callback.
But more important than this, how can an instance tell if there has been a split, and it is not in the primary partition *before* a merge takes place? E.g., in your example of {A,B,C} and {D,E}, how can instance E decide to shutdown and not process requests?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4084399#4084399
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4084399
17 years, 1 month
[Design of JBossCache] - Patch adding transactional putSilent() method
by Cyberax
Please, can you review this patch for addition into the mainline JBoss Cache?
The motivation for this patch
Currently, JBoss Cache adapter for Hibernate uses putForExternalRead() method. This method suspends and then resumes the current transaction and this is slow with some transaction managers, particularly with ones that support transaction recovery. For example, with Atomikos Transaction Manager it takes 25 seconds with putForExternalRead() on my computer to load a big Hibernate model versus 3 seconds with simple put() method in org.hibernate.cache.Cache implementation.
But simple put() method can't be used reliably, because DataVersioningException will be thrown if another thread has loaded the same object and put it in the cache.
Patch details
I've developed this patch to solve this problem. It adds putSilently() method to Cache interface, this method works exactly like putForExternalRead() except that it does not suspend and resume the current transaction. Instead, workspace nodes are marked so they can be ignored during optimistic validation if it fails.
I don't have much experience with JBoss Cache, but this patch works for me (or at least looks like it is working :) ). If the general idea is OK, I'll add mode documentation and unit tests for inclusion into the official JBoss Cache package.
You can get the patch here: http://sd-sup.staffdirector.net/cache.patch
PS: this is a crosspost from JBoss Cache user forum.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4084364#4084364
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4084364
17 years, 1 month