<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.0.4" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>评论：基于MockEJB的CMP实现</title>
	<link>http://www.jiehoo.com/cmp-container-based-on-mockejb.htm</link>
	<description>解己之惑，解人之惑</description>
	<pubDate>Wed, 19 Nov 2008 17:32:16 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.4</generator>

	<item>
		<title>来自：解惑 &#187; 日志 &#187; 成功提高20倍性能</title>
		<link>http://www.jiehoo.com/cmp-container-based-on-mockejb.htm#comment-109</link>
		<pubDate>Thu, 07 Dec 2006 09:45:15 +0000</pubDate>
		<guid>http://www.jiehoo.com/cmp-container-based-on-mockejb.htm#comment-109</guid>
					<description>[...] 这两天其实一直在为性能问题发愁，忙得连日志都没有时间写，前天晚上想到一个解决性能问题的可能方案，结果半宿都没有睡着，脑袋一直在不由自主的想着代码怎么写，但是这个方案只是提高了一倍的性能，今天把代码覆盖的报告又仔细的看了一遍，发现有个方法竟然被调用了两千三百万次，虽然那个代码就是一个直接的return 一个成员变量的语句，但是拿到那个对象后MockEJB会和Aspect进行匹配，需要使用Apache ORO的正则表达式，这个不慢才怪。MockEJB默认使用AspectSystemImpl，它会遍历所有的Aspect，而我的某个测试用例可能会牵涉到20个以上的Entity Bean，每个Entity Bean有三个Aspect，然后调用EJB的每个方法都会这么遍历并且进行匹配，天啊！ 没有办法，自己实现了一个AspectSystem，先把和我的工程无关的调用过滤掉，然后再根据调用的方法解析出对应的Entity Bean，从Map里面查找对应的Aspect（只有三个），这样速度一举提升10倍。刚才那个被调用两千三百万次的方法的调用次数也下降到四十万次左右。 还没有完，还是不满意，原来的那些Pointcut是使用的MockEJB自己带的一个实现类：MethodPatternPointcut，我写的那个表达式还是比较复杂的，想到我已经解析出来对应的Entity Bean了，我只关心方法名或者方法前缀就可以了，就自己实现了Pointcut。 这样修改以后性能又提升一倍。 [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] 这两天其实一直在为性能问题发愁，忙得连日志都没有时间写，前天晚上想到一个解决性能问题的可能方案，结果半宿都没有睡着，脑袋一直在不由自主的想着代码怎么写，但是这个方案只是提高了一倍的性能，今天把代码覆盖的报告又仔细的看了一遍，发现有个方法竟然被调用了两千三百万次，虽然那个代码就是一个直接的return 一个成员变量的语句，但是拿到那个对象后MockEJB会和Aspect进行匹配，需要使用Apache ORO的正则表达式，这个不慢才怪。MockEJB默认使用AspectSystemImpl，它会遍历所有的Aspect，而我的某个测试用例可能会牵涉到20个以上的Entity Bean，每个Entity Bean有三个Aspect，然后调用EJB的每个方法都会这么遍历并且进行匹配，天啊！ 没有办法，自己实现了一个AspectSystem，先把和我的工程无关的调用过滤掉，然后再根据调用的方法解析出对应的Entity Bean，从Map里面查找对应的Aspect（只有三个），这样速度一举提升10倍。刚才那个被调用两千三百万次的方法的调用次数也下降到四十万次左右。 还没有完，还是不满意，原来的那些Pointcut是使用的MockEJB自己带的一个实现类：MethodPatternPointcut，我写的那个表达式还是比较复杂的，想到我已经解析出来对应的Entity Bean了，我只关心方法名或者方法前缀就可以了，就自己实现了Pointcut。 这样修改以后性能又提升一倍。 [&#8230;]
</p>
]]></content:encoded>
				</item>
	<item>
		<title>来自：解惑 &#187; 日志 &#187; 成功提高20倍性能</title>
		<link>http://www.jiehoo.com/cmp-container-based-on-mockejb.htm#comment-108</link>
		<pubDate>Thu, 07 Dec 2006 09:38:41 +0000</pubDate>
		<guid>http://www.jiehoo.com/cmp-container-based-on-mockejb.htm#comment-108</guid>
					<description>[...] 这两天其实一直在为性能问题发愁，忙得连日志都没有时间写，前天晚上想到一个解决性能问题的可能方案，结果半宿都没有睡着，脑袋一直在不由自主的想着代码怎么写，但是这个方案只是提高了一倍的性能，今天把代码覆盖的报告又仔细的看了一遍，发现有个方法竟然被调用了两千三百万次，虽然那个代码就是一个直接的return 一个成员变量的语句，但是拿到那个对象后MockEJB会和Aspect进行匹配，需要使用Apache ORO的正则表达式，这个不慢才怪。MockEJB默认使用AspectSystemImpl，它会遍历所有的Aspect，而我的某个测试用例可能会牵涉到20个以上的Entity Bean，每个Entity Bean有三个Aspect，然后调用EJB的每个方法都会这么遍历并且进行匹配，天啊！ 没有办法，自己实现了一个AspectSystem，先把和我的工程无关的调用过滤掉，然后再根据调用的方法解析出对应的Entity Bean，从Map里面查找对应的Aspect（只有三个），这样速度一举提升10倍。刚才那个被调用两千三百万次的方法的调用次数也下降到四十万次左右。 还没有完，还是不满意，原来的那些Pointcut是使用的MockEJB自己带的一个实现类：MethodPatternPointcut，我写的那个表达式还是比较复杂的，想到我已经解析出来对应的Entity Bean了，我只关心方法名或者方法前缀就可以了，就自己实现了Pointcut。 [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] 这两天其实一直在为性能问题发愁，忙得连日志都没有时间写，前天晚上想到一个解决性能问题的可能方案，结果半宿都没有睡着，脑袋一直在不由自主的想着代码怎么写，但是这个方案只是提高了一倍的性能，今天把代码覆盖的报告又仔细的看了一遍，发现有个方法竟然被调用了两千三百万次，虽然那个代码就是一个直接的return 一个成员变量的语句，但是拿到那个对象后MockEJB会和Aspect进行匹配，需要使用Apache ORO的正则表达式，这个不慢才怪。MockEJB默认使用AspectSystemImpl，它会遍历所有的Aspect，而我的某个测试用例可能会牵涉到20个以上的Entity Bean，每个Entity Bean有三个Aspect，然后调用EJB的每个方法都会这么遍历并且进行匹配，天啊！ 没有办法，自己实现了一个AspectSystem，先把和我的工程无关的调用过滤掉，然后再根据调用的方法解析出对应的Entity Bean，从Map里面查找对应的Aspect（只有三个），这样速度一举提升10倍。刚才那个被调用两千三百万次的方法的调用次数也下降到四十万次左右。 还没有完，还是不满意，原来的那些Pointcut是使用的MockEJB自己带的一个实现类：MethodPatternPointcut，我写的那个表达式还是比较复杂的，想到我已经解析出来对应的Entity Bean了，我只关心方法名或者方法前缀就可以了，就自己实现了Pointcut。 [&#8230;]
</p>
]]></content:encoded>
				</item>
	<item>
		<title>来自：解惑 &#187; 日志 &#187; 条条大路通罗马</title>
		<link>http://www.jiehoo.com/cmp-container-based-on-mockejb.htm#comment-103</link>
		<pubDate>Tue, 05 Dec 2006 11:50:03 +0000</pubDate>
		<guid>http://www.jiehoo.com/cmp-container-based-on-mockejb.htm#comment-103</guid>
					<description>[...] 今天在写测试的用例的时候发现框架的一个Bug，CMP在初始化Entity Bean的时候会自动初始化相关的Entity Bean，但是如果是在一对多的情况下，首先使用的如果是一那端的情况下，不会自动的初始化多那一端的Entity Bean，后来添加了代码修正这个问题后，发现原来只要2分钟运行的所有的测试用例要15分钟才能运行完了，跟踪了一下发现是其中一个测试用例所使用的Entity Bean会连带初始化其他十几个Entity Bean，而且其中有几个Entity Bean的初始数据非常的多，每一个都有300条数据，这样要初始化好需要3分钟，而每个test方法都会来这么一次初始化。后来想着加Cache，Entity Bean填充好以后就缓存起来，后面的test方法再需要初始化的时候就直接进行对象拷贝就可以了，但是Entity Bean在使用的时候会修改一些值，这样如果发生变化的话应该从Cache里面清除，而且需要连带清除所有的Entity Bean。原来缓存的是MockEJB动态创建的Proxy对象，所以要进行对象复制不容易，看了MockEJB的源代码本来想自己也创建一个新的Proxy对象进行复制保存，但是工作量比较大，后来想到的解决的办法就是把对象的属性都复制到一个Map里面，主键是属性的名字，值就是对象值，如果值是集合类型，那么要创建一个同样的集合类并发那个集合里面的全部值加进去。 [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] 今天在写测试的用例的时候发现框架的一个Bug，CMP在初始化Entity Bean的时候会自动初始化相关的Entity Bean，但是如果是在一对多的情况下，首先使用的如果是一那端的情况下，不会自动的初始化多那一端的Entity Bean，后来添加了代码修正这个问题后，发现原来只要2分钟运行的所有的测试用例要15分钟才能运行完了，跟踪了一下发现是其中一个测试用例所使用的Entity Bean会连带初始化其他十几个Entity Bean，而且其中有几个Entity Bean的初始数据非常的多，每一个都有300条数据，这样要初始化好需要3分钟，而每个test方法都会来这么一次初始化。后来想着加Cache，Entity Bean填充好以后就缓存起来，后面的test方法再需要初始化的时候就直接进行对象拷贝就可以了，但是Entity Bean在使用的时候会修改一些值，这样如果发生变化的话应该从Cache里面清除，而且需要连带清除所有的Entity Bean。原来缓存的是MockEJB动态创建的Proxy对象，所以要进行对象复制不容易，看了MockEJB的源代码本来想自己也创建一个新的Proxy对象进行复制保存，但是工作量比较大，后来想到的解决的办法就是把对象的属性都复制到一个Map里面，主键是属性的名字，值就是对象值，如果值是集合类型，那么要创建一个同样的集合类并发那个集合里面的全部值加进去。 [&#8230;]
</p>
]]></content:encoded>
				</item>
	<item>
		<title>来自：解惑 &#187; 日志 &#187; 条条大路通罗马</title>
		<link>http://www.jiehoo.com/cmp-container-based-on-mockejb.htm#comment-102</link>
		<pubDate>Tue, 05 Dec 2006 11:47:59 +0000</pubDate>
		<guid>http://www.jiehoo.com/cmp-container-based-on-mockejb.htm#comment-102</guid>
					<description>[...] 海明威主题的几个问题基于MockEJB的CMP实现下午搬家，提前下班好用的工具会造成思维懒惰？ [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] 海明威主题的几个问题基于MockEJB的CMP实现下午搬家，提前下班好用的工具会造成思维懒惰？ [&#8230;]
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
