为了查看Eclipse GC log，需要在eclipse.ini 中加入 -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -verbose:gc -Xloggc:gc.log 在Eclipse安装目录查看gc.log 9.768: [Full GC 9.769: [Tenured: 7678K->9025K(27328K), 0.3117731 secs] 9172K->9025K(39616K), [Perm : 16383K->16383K(16384K)], 0.3122537 secs] 从上面的日志看似有perm 区(16384K)满引起的Full GC, 需要增大perm区空间和初始空间 -XX:PermSize=64m -XX:MaxPermSize=64m 再重启Eclipse有如下log 1.338: [GC 1.338: [DefNew: 10944K->1028K(12288K), 0.0223470 secs] 10944K->1028K(39616K), 0.0224436 secs] [Times: user=0.03 sys=0.00, real=0.03 secs] 2.053: [GC 2.053: [DefNew: 11972K->434K(12288K), 0.0159322 secs] 11972K->1431K(39616K), 0.0161071 secs] [Times: user=0.01 sys=0.00, real=0.02 secs] 2.923: [GC 2.923: [DefNew: 11378K->1048K(12288K), 0.0192125 secs] 12375K->2044K(39616K), 0.0193916 secs] 貌似初始yong 区空间小了引起yong GC，让初始堆空间跟最大堆空间一样大（yong区应该也会按比例增大吧），GC消除了。 最终eclipse.ini如下 -startup plugins/org.eclipse.equinox.launcher_1.1.1.R36x_v20101122_1400.jar --launcher.library plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.2.R36x_v20101222 -product org.eclipse.epp.package.java.product --launcher.XXMaxPermSize 256M -showsplash org.eclipse.platform --launcher.defaultAction openFile -vmargs -Dosgi.requiredJavaVersion=1.5 -Xms384m -Xmx384m -XX:PermSize=64m -XX:MaxPermSize=64m -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -verbose:gc -Xloggc:gc.log 有趣的是关掉Eclipse会看到如下的log 20.639: [GC 20.639: [DefNew: 104960K->12258K(118016K), 0.2109056 secs] 104960K->12258K(380160K), 0.2110277 secs] [Times: user=0.20 sys=0.00, real=0.20 secs] 31.909: [GC 31.909: [DefNew: 117218K->7351K(118016K), 0.2577353 secs] 117218K->19392K(380160K), 0.2578431 secs] [Times: user=0.24 sys=0.00, real=0.25 secs] Heap def new generation total 118016K, used 37344K [0x02b00000, 0x0ab00000, 0x0ab00000) eden space 104960K, 28% used [0x02b00000, 0x0484a4c0, 0x09180000) from space 13056K, 56% used [0x09180000, 0x098add90, 0x09e40000) to space 13056K, 0% used [0x09e40000, 0x09e40000, 0x0ab00000) tenured generation total 262144K, used 12041K [0x0ab00000, 0x1ab00000, 0x1ab00000) the space 262144K, 4% used [0x0ab00000, 0x0b6c25c0, 0x0b6c2600, 0x1ab00000) compacting perm gen total 65536K, used 36982K [0x1ab00000, 0x1eb00000, 0x1eb00000) the space 65536K, 56% used [0x1ab00000, 0x1cf1d8e0, 0x1cf1da00, 0x1eb00000) No shared spaces configured. 是什么触发了yong GC？关Eclipse时需要创建对象引起GC释放更多的对象？ Yong 区空间118016K + tenured 空间262144K = 380160K, 这约等于我们Xms/Xmx设置的空间。所以xms/xmx大小不包括perm区空间
Sharding(Shared Nothing), 实现scale out的一种方式。其主要目的是为突破单节点数据库服务器的I/O能力限制，解决数据库扩展性问题。适用用业务逻辑上独立的数据，bloger,digger上单个user的数据。Shard可以根据ID,时间段，表来划分。 如果结果涉及多个shard，可以在应用层抽象出一个数据库操作接口，对从多个shard取回的结果进行merge, sort之类的操作。
磁盘IO问题，解决方法之一是cache 比如在应用服务器和数据库之间加入memcached.磁盘IO主要原因之一是大量文件读写操作，比如图片，音频，视频的读写。不管是直接从文件还是从数据库，都会造成大量的IO Web Server前（如Apache Server）加入squid(Reverse Proxy) 我是这么理解的：Forward Proxy配在客户浏览器端，如局域网通过这种代理上网Reverse Proxy配在Web Server端，作为cache. 可不可以作为Redirect /load balance 不是很确定。 IBM Edge Server应该属于此类。
InnoDB和MyISAM是在使用MySQL最常用的两个表类型，各有优缺点，视具体应用而定。基本的差别为： MyISAM类型不支持事务处理等高级处理，而InnoDB类型支持。 MyISAM类型的表强调的是性能，其执行数度比InnoDB类型更快，但是不提供事务支持，而InnoDB提供事务支持以及外部键等高级数据库功能。
portlet request divide into action request and render request Render parameters allow the portlet to store its navigational state. Render parameters stay the same for subsequent render requests and only change when the portlet receives a new action. This enables bookmarkability and solves the browser back button problem. portlet request: a call from from the client (portal server) to process some information or render some markup. A portlet request is received and managed by a portlet container. The portlet container executes the targeted portlet to process the request. There are two things that distinguish portlet requests from typical http (web requests): the client sending the portlet request is a portal application not an end user (browser) and multiple (two) requests are sent to submit data and render a markup response. portlet request scope: the duration of a request processed by the portlet container. Because portlets separate action processing and rendering in two distinct requests, client state stored in the request scope does not carry forward from a portlet's action to its render. JSF Bridge As Faces executes in the context of an underlying container its request scope is restricted by that provided by the container. However, the Faces model is based on the servlet model and hence expects a single request for processing both user interactions and rendering. Because this isn't the behavior in a portlet container, Faces does not execute properly if the Faces application depends on request scoped data established during action processing and referenced during rendering. the bridge preserves data stored at request scope so that it can be restored on subsequent render requests. I.e. where in a regular portlet environment, each action and render request processing starts with an empty data set in its request scope and any data added to this scope during processing is destroyed when the request completes, the bridge preserves this state and restores it into the request scope on subsequent render requests.
The life cycle handles both kinds of requests: initial requests and postbacks. When a user makes an initial request for a page, he or she is requesting the page for the first time. When a user executes a postback, he or she submits the form contained on a page that was previously loaded into the browser as a result of executing an initial request. When the life cycle handles an initial request, it only executes the restore view and render response phases because there is no user input or actions to process. Conversely, when the life cycle handles a postback, it executes all of the phases. Restore View builds the view root and saves to FacesContext, includes event handlers and validators if it is the initial reqeust, empty view created and life cycle advances to render response directly. Apply Request Value component extracts its new value from the request parameters. Type conversion occurs in this phase. if renderResponse called on FacesContext, skip to the render response phase. FacesContext.responseComplete can be called, and redirect to a different web app if immediate set to true, the validation, conversion,events will be processed in the phase. Process Validations process validators registered on the components. if any error message, the life cycle advances directly to the render response phase. if FacesContext.renderResponse called, skip to the render response phase if FacesContext.responseComplete called, redirect to a different web app Update Model value update component value to manage bean property similarily for FacesContext.responseComplete similarily for FacesContext.renderResponse Invoke Application handle application-level events similarily for FacesContext.responseComplete Render Response if JSP pages used, the components will render themselves as the JSP container traverses the tags in the page. if this is the initial request, the components represented on the page will be added to the component tree as the JSP container executes the page.
API Layer 事务策略的命名基于这样一个事实：所有事务逻辑包含在逻辑应用程序架构的 API 层。这个层是一个逻辑层 — 有时也被称为应用程序的域层（domain layer）或 facade 层，它以公共方法或接口的形式向客户机（或表示层）公开功能。之所以说是逻辑 层，是因为可以从本地访问域层（通过直接实例化和调用），或通过 HTTP、远程方法调用（RMI）、通过 EJB 使用 RMI over Internet Inter-Orb Protocol (RMI-IIOP)，甚至通过 Java Message Service (JMS) 进行远程访问。 只有包含在应用程序架构的 API 层中的公共方法包含事务逻辑。其他方法、类或组件都不应包含事务逻辑（包括事务注释、编程式事务逻辑和回滚逻辑）。 API 层中的所有公共写方法（包括插入、更新和删除）都应当使用事务属性 REQUIRED 加以标记。 API层中的所有公共写方法（包括插入、更新和删除）都应当包含回滚逻辑，以标记对检查出的异常执行回滚的事务。 API 层中的所有公共读方法默认情况下都应使用事务属性 SUPPORTS 加以标记 对于 LUW （Logic Unit of Work)请求，应用程序使用 85% 的单 API 层调用和 15% 的多 API 层调用。对于多API层调用解决的方法是使用一个聚合 API 层方法将多个 API 调用重构为一个单一的 API 调用。
CMMI Maturity Levels: Level-1: Chaotic, individual heroics Level-2: Managed processes are planned, documented, monitored, and controlled at the project level Level-3: Defined processes are described in standards, procedures, tools and methods Level-4: Quantitatively Managed Processes are controlled using quantitative techniques Level-5: Optimizing Continually improving process performance