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#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...