此为LighTECHs的熊昊一的最新作品...
[url=http://code.google.com/p/jworkpool/]jWorkPool HomePage[/url]
I have ever met a problem that Lucene would lock the files of index when we do writing actions, so in a multi-`thread environment, if we only apply traditional Java Asynchronized keyword for sharing this mutex resource, the effect of index writing would be lower. For that, we introduced JSR166 (JDK1.5 java.util.concurrent) Lea 1999 into our project. Indeed, personally, I capsulated this framework with Spring as my own framework jWorkPool 6 for my mates at first. As my plan, a multi-thread oriented work process is cut into several Work Services by their function and the mutex resources that them accesses, moreover each Work Service has its defined Work Pool for running. Programmers could configure the size of Work Pool to control and optimize the mutex resources' sharing. For example, we use Fixed-Single-Workpool to run the work services for Lucene index writing, only one work service can run in the pool while other submitted work services are waiting in the waiting list. I also design SessionContext, each of which contains variables of a work process among a series of services, and maintain the state of work process. In additional, each service has its "next" service which is injected into service by Spring IoC, and stands for the next service to invoke in process. An abstract class "Router" is defined as a special kind of service which could cipher out what's to do next by variables in SessionContext, and control the process. What's more, the most exciting character of jWorkPool is that Work Services and Work Pool I mentioned above need only configure in Spring Beans XML. That means Beans XML can present the work processes just like BPEL. For more information about this kit please check the homepage of project. Finally we implement the whole business logic in Work Services, and applying jWorkPool shows us a higher performance.
[url=http://www.iadis.net/dl/Search_list_open.asp?code=5364]Semantic web tech[/url]
[url=http://code.google.com/p/jworkpool/]jWorkPool HomePage[/url]
I have ever met a problem that Lucene would lock the files of index when we do writing actions, so in a multi-`thread environment, if we only apply traditional Java Asynchronized keyword for sharing this mutex resource, the effect of index writing would be lower. For that, we introduced JSR166 (JDK1.5 java.util.concurrent) Lea 1999 into our project. Indeed, personally, I capsulated this framework with Spring as my own framework jWorkPool 6 for my mates at first. As my plan, a multi-thread oriented work process is cut into several Work Services by their function and the mutex resources that them accesses, moreover each Work Service has its defined Work Pool for running. Programmers could configure the size of Work Pool to control and optimize the mutex resources' sharing. For example, we use Fixed-Single-Workpool to run the work services for Lucene index writing, only one work service can run in the pool while other submitted work services are waiting in the waiting list. I also design SessionContext, each of which contains variables of a work process among a series of services, and maintain the state of work process. In additional, each service has its "next" service which is injected into service by Spring IoC, and stands for the next service to invoke in process. An abstract class "Router" is defined as a special kind of service which could cipher out what's to do next by variables in SessionContext, and control the process. What's more, the most exciting character of jWorkPool is that Work Services and Work Pool I mentioned above need only configure in Spring Beans XML. That means Beans XML can present the work processes just like BPEL. For more information about this kit please check the homepage of project. Finally we implement the whole business logic in Work Services, and applying jWorkPool shows us a higher performance.
[url=http://www.iadis.net/dl/Search_list_open.asp?code=5364]Semantic web tech[/url]
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
