anonymous wrote : 1. Use OrdereredExecutorFactory for thread management. This should make the global pager redundant. I have this done on my local copy already.. I'm just waiting some tests to finish before I commit this tomorrow. anonymous wrote : 3. Much of the functionality currently in PagingManagerImpl is better placed in PagingStoreImpl, e.g. addSize, ondePage. This would also simplify the code since less lookups would be needed and several methods could be removed or made private. done anonymous wrote : 4. PagingStoreImpl - The locking is very complex. Can this be simplified by using Condition objects with the lock? Or perhaps we can disallow concurrent writes to the same page - which would simplify the locking. IS there really much performance to be gained by concurrent writes to the same page? Can this be verified with a test? The readWriteLock is used to avoid synchronized access on the verification on isPaging(). I wanted to not create any contention when paging is not activated. I have changed the code not allow multiple writes, but the lock schema is pretty much the same. anonymous wrote : | 6. PagingStoreImpl::page() | | Calculation of block size and lock acquisition: | | done anonymous wrote : | 7. PagingStoreImpl::page | | pagedUsedSize is being incremented twice? | | Not really.. openNewPage is setting it to 0, then it needs to be added again. anonymous wrote : | 8. TransactionImpl: | | An address can switch from paging to not paging mid way during a transaction before it is committed, resulting in the transactions messages being routed out of order | | 9. TransactionImpl: | | Currently paged messages are paged on commit(). If there are a lot of paged messages this could hold up the remoting thread for a significant amount of time, | | One of the design principles of the server is each operation should be quick to complete to avoid starving other operations.l | | We should consider instead, writing transactional actions straight to a file in the paging case, then on commit, since we know they are on file we can process them on a different thread and the commit can return ok immediately. This would also allow us to deal with huge transactions, much bigger than can fit in memory at once | | I want to do that as part HugeTransaction task. anonymous wrote : 10. Currently routing code is duplicated in ServerSessionImpl::send, TransactionImpl and in depage logic. This should be put in one place. This goes beyond of paging... but I will do that tomorrow. I'm still missing 2, but that should be easy. (Unless we decide to do something more complex such as hole-detection the way I have done on the Journal). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193911#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...