JBoss Group Unveils JBossCache

Discussions

News: JBoss Group Unveils JBossCache

  1. JBoss Group Unveils JBossCache (23 messages)

    JBoss Group has released an AOP enabled caching solution named JBossCache. JBossCache can be either local or replicated, and performs functionality such as locking, replication and transaction management.

    The AOP subclass allows for replication of any POJO. The AOP-enabled cache automatically analyzes an object when it is inserted in the cache and knows exactly when any field has been changed.

    Bela Ban, creator of JavaGroups, has been leading this project.

    JBossCache will feature the following services:

    - JNDI (Java Naming and Directory Service), a fail-safe lookup service that will be distributed.

    - HTTP Session Replication, which is critical for integrating the Tomcat Web container, making transactions available on all nodes, so a server crash is invisible at the application level.

    - Stateful Session Bean (SFSB) Replication, which allows objects to be replicated to all servers.

    - Entity Bean Replication, which is important for clustering. This allows caching of entity beans without going to database or having to serialize those objects. The ability to cache in memory, locally results in huge performance gains, in some cases speed increases by a factor of 20.

    Press Release: JBoss Group Introduces JBossCache

    Threaded Messages (23)

  2. JBoss Group Unveils JBossCache[ Go to top ]

    Congratulations to Bela Ban and Ben Wang on getting the first release out.
  3. Congratulations to JBossCache[ Go to top ]

    I really hope to meet JBossCache. I think it's really useful!!!
    I will test it and then apply my application!!!
    Congratulations to JBossCache again!!!
  4. Cache details and comparison?[ Go to top ]

    I'm glad to see a caching service being added to the architecture.. I would be interested to see more technical details however. I couldn't find anything on the jboss.org web site with details, API information, or other such useful things.

    Also, any timing or performance tests would be interesting to see.
  5. Cache details and comparison?[ Go to top ]

    The docs shipped with the distro should cover most of your questions. If you look into jboss-head/cache/docs in the CVS, you'll find more details (e.g. design docs etc).

    In terms of performance, I have slides that I show at JBoss bootcamps. Also, we ship perf tests with the testsuite (under 'cache'). You can run them youself.

    I hope I'll be able to provide some more exhaustive perf numbers by the end of Jan/mid Feb, as I will have access to a lab for testing.

    Bela
  6. I am very interested in looking at your "exhaustive perf numbers". We are putting together a business critical caching solution and need to understand JBossCache performance metrics from a realistic deployment scenerio.

    Where can I view these perf numbers?

    -Travis
  7. docs[ Go to top ]

    http://www.jboss.org/index.html?module=html&op=userdisplay&id=developers/projects/jboss/cache/index.html

    Regards,

    Bill
  8. new address[ Go to top ]

    Hi,

    Looks like they have a new address:
    http://www.jboss.org/developers/projects/jboss/cache/index.html
  9. OFF: Hungarian?[ Go to top ]

    Sorry, this is an offtopic question: are you hungarian, Bela?
  10. OFF: Hungarian?[ Go to top ]

    Yes, Hungarian and Swiss ... Both passports, but I don't actually speak any Hun garian. The closest I ever came to Hungarian is when I used Hungarian notation, in my good old Windows days :-)

    Bela
  11. JBoss Group Unveils JBossCache[ Go to top ]

    this will change the world!

    Holger
  12. JBoss Group Unveils JBossCache[ Go to top ]

    Look like guys from JGroup write another good thing.
    Very very good job. Just cvs co it and see perfect
    code with JGroup replication, concurrent.jar usage and so on.
    Again, very good thing
  13. Isolation Levels?[ Go to top ]

    Some questions:

    What isolation levels do you provide in JBossCache?

    More specifically, do you block (waiting for locks) and/or roll back? And do you keep the locks until the end of the transaction?

    I am asking because when it comes to distributed caches with off-the-shelf hardware and software there are no free lunches. The only concurrency control protocol that seems to scale well seems to be optimistic concurrency control with data invalidation and rollbacks.

    Also, since JBossGroup is a commercial enterprise, are there plans to establish a partnership with Voltaire, TopSpin or other infiniband vendors? With infiniband you'll spend a couple of thousand dollars per node but you will be able to hold locks until the end of the transaction, and not have to endure rollbacks. Voltaire sells an inexpensive infiniband kit plus drivers for linux. Perhaps JBoss could write Java wrappers for these drivers ..

    Also, are you using total ordering to implement locks (if indeed you use locks) or something else (causal ordering perhaps?) And if you are using total ordering are you using a ring-based protocol or a sequencer?

    Guglielmo
  14. Isolation Levels?[ Go to top ]

    What isolation levels do you provide in JBossCache?
     
    More specifically, do you block (waiting for locks) and/or roll back? And do you keep the locks until the end of the transaction?


    Your questions are answered here:

    http://www.jboss.org/developers/projects/jboss/cache/TreeCache.html
  15. Isolation Levels?[ Go to top ]

    Your questions are answered here:

    >
    > http://www.jboss.org/developers/projects/jboss/cache/TreeCache.html

    Thank you. This is what I found:

    "Note that the cluster-wide isolation level is by default read-uncommitted because we don't acquire a cluster-wide lock on touching an object for which we donít yet have a lock (this would result in too much overhead for messaging)"

    Since this says "by default", it would seem to imply that I can change the cluster isolation level to something else. This, however, would seem to contradict this earlier statement:

    "[when a] change is done in the context of a transaction, then we wait with replication until the TX commits successfully."

    So basically, the answer is "READ_UNCOMMITTED" only.

    The reason I am pointing this out is that performance numbers are meaningless when divorced from the isolation level. The isolation level determines the communication overhead of the concurrency control protocol.

    This is also relevant:

    "When the transaction commits, we initiate a two-phase commit protocol[7] : in the first phase, a PREPARE containing all modifications for the current transaction is sent to all nodes in the cluster."

    So you are doing the old 2PC protocol. But if you do this you incur a lot of overhead for each transaction. I would be curious to see what kind of throughput you will get from a fully-shared workload of short transactions. It should be pretty bad.

    Given that JavaGroups also has totally-ordered reliable multicast, isn't there a better solution? Basically you would use local-read, replicated-write (including locks). The best-case *latency* would be worse, but the worst-case *throughput* would be much much better.

    No? Bela, your thoughts on this?

    Thanks
    Guglielmo
  16. Isolation Levels?[ Go to top ]

    "Note that the cluster-wide isolation level is by default read-uncommitted because we don't acquire a cluster-wide lock on touching an object for which we donít yet have a lock (this would result in too much overhead for messaging)"

    >
    > Since this says "by default", it would seem to imply that I can change the cluster isolation level to something else.

    Yes, correct.

    > This, however, would seem to contradict this earlier statement:
    >
    > "[when a] change is done in the context of a transaction, then we wait with replication until the TX commits successfully."


    how does this contradict my earlier statement? These are orthogonal issues: the latter determines when to replicate, the former what type of locks to use.


    > So basically, the answer is "READ_UNCOMMITTED" only.

    No.


    > The reason I am pointing this out is that performance numbers are meaningless when divorced from the isolation level.

    I agree.

     

    > So you are doing the old 2PC protocol.

    Yes - old and proven :-)

    > But if you do this you incur a lot of overhead for each transaction.

    Yes. however, I only use 2PC when the cache is configured for synchronous replication. For asynchronous replication, of course I don't run a 2PC protocol.
    Again, this comes back to what I referred to in the announcement: you can configure the cache to have either high performance or high reliability, the latter requires 2PC.
    Note, that even when we introduce optimistic locking, you will still have to do 2PC.

    > Given that JavaGroups also has totally-ordered reliable multicast, isn't there a better solution? Basically you would use local-read, replicated-write (including locks). The best-case *latency* would be worse, but the worst-case *throughput* would be much much better.

    As I mentioned previously, there is interesting research on the subject of database replication on top of group communication. They seem to have gotten pretty good performance out of it, using total order. However, this is still research, and I wanted to provide a product that can be used now.
    Cheers,
    Bela
  17. Isolation Levels?[ Go to top ]

    how does this contradict my earlier statement? These are orthogonal issues: the latter determines when to replicate, the former what type of locks to use.


    Are you differentiating between locking in the same vm and between different vms?

    > > The reason I am pointing this out is that performance numbers are meaningless when divorced from the isolation level.
    >
    > I agree.

    Good :)
  18. Isolation Levels?[ Go to top ]

    how does this contradict my earlier statement? These are orthogonal issues: the latter determines when to replicate, the former what type of locks to use.


    So, if I understand correctly:

    1. Within a single VM you enforce a configurable isolation level

    2. Between different machines you enforce READ_UNCOMMITTED, because the replication uses 2PC.
     
    The problem I have with this is that two transactions 'see' each other differently depending on whether they are co-located or not. And there is no a priori mechanism for putting transactions in the same vm. Therefore, what I don't like about this approach is the lack of a single-system image.

    I understand that locking every object across the cluster as it is accessed is too expensive, but I do not concede that the only way to do this is using two-phase commits.

    If you think about, the current approach is closer to traditional (log-based) database replication than it is to a cluster.

    I would like to propose a different approach: the operation of the system consists of reads and writes. The reads should be done locally. The writes include data updates and locks. I believe the approach that maximizes peak throughput is ring-based, totally-ordered reliable multicast. This is already implemented in JavaGroups (TOTEM protocol.) Using a small ring of cots hardware, you can easily achieve a throughput of 5,000 messages per second at a latency of , say, 10-20 ms (which is the time it takes the token to go around the ring with the CPU busy 100% handling messages.) The nice thing about total ordering is that there is NO 2-phase commit. To do a write (including getting a lock), you simply send a message out.

    On the surface, this approach compares unfavourably with the current approach (more communication, in fact the cpu is quite busy), but since the data is replicated synchronously, you get a bonus feature: DURABILITY. Ken Birman discusses this in his book on fault tolerance. If a machine dies, the transaction does not get rolled back. This means that the changes can be applied to the database with a much longer delay. And if you have a small amount data, you basically have an in-memory database with decent durability.

    There is another reason why this is the way to go: Infiniband, specifically user-space, remore-direct-memory-access (RDMA) is picking up, so much so that nowadays you can scale both DB2 and Oracle horizontally on a cluster, which is an entirely new approach. The current cost of using an infiniband network is about $2,000 per node, and it will likely go down quickly. And the latency of cluster caches can go down as well.
  19. Isolation Levels?[ Go to top ]

    1. Within a single VM you enforce a configurable isolation level

    >
    > 2. Between different machines you enforce READ_UNCOMMITTED, because the replication uses 2PC.
    >
    > The problem I have with this is that two transactions 'see' each other differently depending on whether they are co-located or not. And there is no a priori mechanism for putting transactions in the same vm. Therefore, what I don't like about this approach is the lack of a single-system image.


    No, maybe my previous reply was unclear: we in force isolation levels across the entire cluster. So if you use and isolation level of serializable, we will have serializable properties across the cluster.

     

    > If you think about, the current approach is closer to traditional (log-based) database replication than it is to a cluster.

    yes, I never claimed anything else.

     
    > I would like to propose a different approach: the operation of the system consists of reads and writes. The reads should be done locally. The writes include data updates and locks. I believe the approach that maximizes peak throughput is ring-based, totally-ordered reliable multicast. This is already implemented in JavaGroups (TOTEM protocol.) Using a small ring of cots hardware, you can easily achieve a throughput of 5,000 messages per second at a latency of , say, 10-20 ms (which is the time it takes the token to go around the ring with the CPU busy 100% handling messages.) The nice thing about total ordering is that there is NO 2-phase commit. To do a write (including getting a lock), you simply send a message out.
    >
    > On the surface, this approach compares unfavourably with the current approach (more communication, in fact the cpu is quite busy), but since the data is replicated synchronously, you get a bonus feature: DURABILITY. Ken Birman discusses this in his book on fault tolerance. If a machine dies, the transaction does not get rolled back. This means that the changes can be applied to the database with a much longer delay. And if you have a small amount data, you basically have an in-memory database with decent durability.


    there is an interesting paper on this Object available from the University of Zurich (ETH) from the Dragon project, which describes essentially database replication on top of the group communication. they claim that by a using optimistic locking and total order group protocols, they can essentially avoid a two phase commit protocol. Instead of sending a prepare and the commit or rollback message, they always send only one broadcast. So instead of 2 broadcasts and n unicasts ( where n is the number of members in the group), the send only one asynchronous broadcast. This completely eliminates latency from the system, improving performance.
    Of course, Total Order is costly as well. So one has to weigh the trade-offs between using the two phase commit protocol and total order, and the right choice.

    Once I have optimistic locking in place, I would like to experiment with this concept a little bit more, and compare the results with my traditional to phase commit protocol approach.

    I can post the URL of the paper I mentioned before here if anybody's interested.
    Regards,
    Bela
  20. Isolation Levels?[ Go to top ]

    Some questions:

    >
    > What isolation levels do you provide in JBossCache?


    The isolation levels we provider similar to the once known in database technology: NONE, READ_UNCOMMITTED, READ_COMITTED, REP_READ and SERIALIZABLE. They are described in more detail in section 5 of the TreeCache documentation.
     
    > More specifically, do you block (waiting for locks) and/or roll back? And do you keep the locks until the end of the transaction?

    yes, we currently use pessimistic locking and acquire locks per transaction. We keep the lock until the end of the transaction.


    > I am asking because when it comes to distributed caches with off-the-shelf hardware and software there are no free lunches. The only concurrency control protocol that seems to scale well seems to be optimistic concurrency control with data invalidation and rollbacks.

    optimistic locking is planned; I have the design for it, but I haven't yet implemented it.

     
    > Also, since JBossGroup is a commercial enterprise, are there plans to establish a partnership with Voltaire, TopSpin or other infiniband vendors? With infiniband you'll spend a couple of thousand dollars per node but you will be able to hold locks until the end of the transaction, and not have to endure rollbacks. Voltaire sells an inexpensive infiniband kit plus drivers for linux. Perhaps JBoss could write Java wrappers for these drivers ..

    not that I know of. I'm not really familiar with Infiniband, but as far as I know Infiniband only helps you when all the nodes in the cluster are are on the same machine. If this is true, if the server crashes, and your hosed anyway. The TreeCache is supposed to be a software only solution, to replicate data across nodes in a cluster, where the nodes are located on separate machines.

    That could use case is session replication, where there are for example machines that replicate the sessions to each other. Using sticky sessions, a client always goes to the same machine. When that machine crashes the client fails over to the other machine.


    > Also, are you using total ordering to implement locks (if indeed you use locks) or something else (causal ordering perhaps?) And if you are using total ordering are you using a ring-based protocol or a sequencer?

    no, I'm currently not using total ordering, I only use FIFO. In the future, I will look at total ordering. I read a paper that suggested that if total ordering was used in database replication, performance would be much better. The referred to a ring based total token based protocol.
    Cheers,
    Bela
  21. InfiniBand Support for Java[ Go to top ]

    Guglielmo,

    just noticed your post

    Voltaire has full support for Java including low latency Java NIO based communication

    a solution is closer to thousand dollars per node (much under 2,000)

    Yaron
    yaronh@voltaire.com
  22. Cache size[ Go to top ]

    Can I set the size of the cache in MegaBytes, Max No. of object etc. If I can set the size what happens when limit is reached. It uses LIFO to expire objects etc. I did not see any mention of size at
    http://www.jboss.org/developers/projects/jboss/cache/TreeCache.html
  23. Cache size[ Go to top ]

    Can I set the size of the cache in MegaBytes, Max No. of object etc. If I can set the size what happens when limit is reached. It uses LIFO to expire objects etc. I did not see any mention of size


    Currently, eviction policies are not really implemented. We do provide hooks for eviction policies, but we don't have a default implementation.
    The reason for this is that TreeCache was implemented with a model in mind, that had somebody else in charge of eviction, for example the old JBoss persistence Manager, or Hibernate. in the example of hibernate, it is hibernate that is in control of the cache: hibernate tells me to add data and hibernate also tells me to remove data, e.g. when data is evicted from the cache.

    However, an eviction policy implementation is in the works. I need it when I want to provide a JCache compliant implementation.
    Cheers,
    Bela
  24. Eviction Policy[ Go to top ]

    Currently, eviction policies are not really implemented. We do provide hooks for eviction policies, but we don't have a default implementation.

    > The reason for this is that TreeCache was implemented with a model in mind, that had somebody else in charge of eviction, for example the old JBoss persistence Manager, or Hibernate. in the example of hibernate, it is hibernate that is in control of the cache: hibernate tells me to add data and hibernate also tells me to remove data, e.g. when data is evicted from the cache.

    I like the idea of having no eviction policy (at least as an option). So I can use it as an easy to use distributed in-memory replication tool (with content to be garantueed) rather than a distributed cache, right?