[Design of JBossCache] - Distributed lock manager
by manik.surtani＠jboss.com
Referencing this thread and various other discussions.
Is the subject something we want to implement in JBoss Cache in some shape or form, at some stage?
I agree that here are scalability issues with such a feature, but is it not fair comment to say that there are use cases where this is critical, our competitors have this in some shape, and it may be a good idea to offer it?
Specifically looking at a recent support case where each node in a cluster would, within the scope of a tx, read from the cache, increment the value read, and replace the value in the cache. So a write-mostly scenario here. And this would, when used with SYNC_REPL, inevitably deadlock after some while.
Also, two of our most high-profile competitors - Tangosol and Terracotta - both have some form of distributed locking. Each one implemented differently, but it is there all the same.
The purpose of this thread is to discuss potential implementations and how this would work with JBoss Cache.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4027285#4027285
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4027285
19 years
[Design of JBossCache] - JBCACHE-1004 and JBCACHE-1005
by manik.surtani＠jboss.com
For the next beta of JBoss Cache 2.0.0, I've taken the public APIs a step further by genericising them.
This is in CVS right now. Feedback on this new, genericised API is much appreciated.
Affected classes/interfaces are: Cache, CacheSPI, Node, NodeSPI, Fqn, CacheFactory.
My reasoning behind genericising has been that while a lot of people would still want a cache that holds generic Objects, certain degree of control as to the type can be useful. For example, enforcing the elements that make up an Fqn or what objects can be used as keys.
One of the issues here is that if you decide to specify what you want in your cache (keys and values) you'd need to specify this when creating the cache using the cache factory, and these types are then used whenever Nodes are created.
Typical usage pattern:
|
| // example where we want all keys to be integers and all the objects in the cache are Strings.
| CacheFactory<Integer, String> cf = DefaultCacheFactory.getInstance();
| Cache<Integer, String> cache = cf.createCache();
|
| Fqn<String> myFqn = Fqn.fromString("/a/b/c");
| Node<Integer, String> node = cache.getRoot().getChild(myFqn);
|
| node.put(33, "Hello world");
|
Does this relative inflexibility mean that most people would just create Cache<Object, Object> anyway?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4027284#4027284
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4027284
19 years
[Design of JBoss ESB] - Re: Why Using JBossESB?
by tfennelly
Hi Goldi.
We're just a few days from code freeze for a maintenance patch to the 4.0 GA release, so please excuse the delay in replying.
Right now, I'm not in a position to do a feature by feature comparison between Servicemix etc and JBoss ESB. Anyway, this is probably something that would be better done by a neutral party - we'd surely be biased in favor of JBoss ESB ;-) Hopefully we'll have more time to contribute to something like this once we get this maintenance patch out the door.
However, I would make the following general points about JBoss ESB:
1. JBoss ESB is based on a codebase which has been in a production deployment for nearly 4 years. This is something that cannot be said of the other implementations.
2. In a very short period of time, we have built a very vibrant community around JBoss ESB. There are 6 full time members of the team and 14 community members. This community is vibrant because the people involved are given the opportunity to provide input on the future direction of the project (architecture etc).
3. Being a JBoss project means that JBoss ESB has access to a wide range of resource at JBoss/RedHat. This also means that we are in a much better position to evolve JBoss ESB as part of a more integrated solution involving not only other JBoss middleware products (JBoss App Server etc), but Red Hat products too - see Red Hat App stack.
So, ServiceMix etc may have a one or two features that JBoss ESB doesn't have right now (and visa versa I might add!), but I'm confident that this is something that we are rapidly overcoming. Add to that the fact that JBoss has a proven track record for delivering quality middleware products and services and then I think JBoss ESB has a very bright future.
Sorry for the short reply Goldi, but I hope this gives you something to think about.
T.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4027180#4027180
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4027180
19 years