Hi, I thought I'd offer an idea that struck me this morning regarding buddy backup. Consider the following start of a tree: /root/ | /A | /B | /C In our scenario, changes on nodes A-C (including optional sub-trees) may be performed concurrently per node but the system guarantees that even though one thread may change A while another changes B no two threads will ever try to access the same node at the same time.
However, given a number of "node executing" threads for concurrency, buddy replication becomes somewhat of a bottle neck as A-C will all be backed up on the same remote node. For example, using TCP/UNICAST in the configuration will force all threads involved to lock on to the same monitors during replication as all backups are located on the same remove instance. This led me to suspect that perhaps, and this is where you can tell me why I'm dead wrong of course, that some sort of "region based buddy backup" would yield a drastically improved performance for this kind of scenarios, as it would enable concurrent transport for all three nodes. In other words, given remote nodes N1, N2, and N3 and you could configure the cache as follows... /root/A (with subtree) - to be buddy backed up at N1 | /root/B (with subtree) - to be buddy backed up at N2 | /root/C (with subtree) - to be buddy backed up at N3 ... thread T1 could concurrently access and replicate A without interfering with thread T2 which is accessing B as 1) they're on different sub-trees in the cache (thus in-VM locking shouldn't be a problem); and 2) replication can be done concurrently (FIFO ordering etc). Am I making any sense here? Cheers /Lars J. Nilsson www.cubeia.com View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4148773#4148773 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4148773 _______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
