"jarquey" wrote : In the solution you suggest it will be application responsibility to manage the cache consistency during transfer ? I don?t see how to manage it ? |
The application could for example communicate with all members to stop modifying the cache until the state transfer (e.g. DB copy) is done. However, this boils down to what we already have. There is no way around locking the entire tree until the state has been copied, at least not IMO. anonymous wrote : | About cache lock during transfer : | Is it stupid to imagine that the JbossCache coordinator will manage only iterative Treecache nodes locks (for instance at Treecache root level) instead of a global cache lock during synchronization ? Sync time could be longer but the sync could remain secure, allow concurrent transactions and avoid application unavailability. | The problem here is that you can get inconsistencies when you lock node X to get its state, then unlock, but before you transfer the state, someone else modifies X. I'm not sure it *cannot* be done, but it would have to result on consistent state snapshots. Note that this problem will somewhat be mitigated with optimistic locking (scheduled for 1.2.5, Oct 2005): we will still need to lock the entire tree, but because there are no other locks in the tree (except when a TX commits), this should be okay. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884399#3884399 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884399 ------------------------------------------------------- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar _______________________________________________ JBoss-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-user
