We will discuss the concept of checksum in Agile PLM and related technology. If enabled Checksum Calculation in Agile PLM, we may see below error when do CheckOut/CheckIn file attachment. This scen...

I have been asked by customers and partners about one same puzzle that why IQuery.execute() runs extremely fast, while the first time execution of Iterator.hasNext() runs very slow。To answer and su...

Java中的线程池溢出，是个比较难诊断的问题。它的成因是多个任务（比如HTTP请求）等待执行，因为每个thread在一个时间点上只能执行一个task，如果线程池最多可以容纳20个线程，涌进来30个任务，那么只有20个任务才能得到执行，剩下的10个必须等待池中出现闲置的线程。如果有一些执行的任务很耗时，后面的任务将长时间得不到线程资源供执行，线程池溢出的问题就会发生。 很多web服务器都提供...

Java线程问题中最为常见的成因是资源竞争，它导致的后果是服务器停止响应，或者CPU过高使用。资源竞争非常好理解，就是一个或者多个线程等待某个资源，而这个资源又被另一个线程所占有并长时间不能释放。对于这种情形，Thread Dump中的“waiting for monitor entry”就非常重要。 代码演示 我假设有这样一个例子，三个小孩分享同一块面包，但是必须排队一个接一个地分享。...

Java中谈线程问题必谈死锁，这种现象很奇怪。因为死锁的发生还是比较少见的，它是经典的线程问题但绝对不是常见的。它一般不会引起CPU使用过高，相反地，它会使得服务器停止对客户请求的响应。死锁的问题很容易就能从Thread Dump中识别出来。 这里有一点需要明确的是：死锁和CPU过高使用没有必然联系。但是网络上经常讲CPU过高和Java线程就归纳到死锁上来。这是不正确的。线程问题有很多种类...

Java线程问题中有一类现象很常见，就是CPU过高使用。有时你能看到400%的使用率，这是因为多核的原因，实际也就是100%或者99%而已。什么样的情况导致CPU过高，很难讲，情况太多，比如硬件资源、不好的算法、太过持久的IO吞吐等，都可能是成因。下面通过简单的例子，演示如何从Thread Dump中找到有问题的那个线程，直到有问题的代码行。 代码例子 这个代码只是演示而已，没人会这么写...

When you use Agile API to develop SDK customization to extend your functionality, you may not care about how SDK architecture is designed by Agile smart engineers and you only focus attention on yo...

PMON主要做的事情包括连接进程异常中止后的资源清理，后台进程状态的监控与恢复，以及将实例注册到Listener上。本文通过一些调试例子来分析背后的工作原理。 连接进程的异常清理 我们使用10246事件来调试。由于10246只能用在initSID.ora中而不能动态地alter system，因此我们通过pfile方式启动数据库，启动前先在initSID.ora文件中加入这样的调试参数：...

企业应用中有时会使用到文档类文件的上传和下载。为了保证文档在传输和存储过程中没有被恶意篡改过，就可以使用Checksum对文件进行校验。比如在上传文件的同时，计算出文件的Checksum，保存到数据库中。当其他用户需要下载该文件时，对服务器上保存的该文件进行第二次的Checksum计算并和数据库中的值进行比较验证。 对于文件的checksum校验有非常多的方法，常见的有SHA1, MD5和...

写完用getopts处理全部的选项和参数</a>后，我注意到了获取所有参数的特殊变量$@，要不要加双引号，对参数的处理有很大影响。另外linux还是有个也是读取所有参数的特殊变量$*，引用他们时，加不加双引号变化很大。索性一并测试一下，总结一下它们的规律特点，分别是: $* "$*" $@ "$@" $* 不加双引号：参数列表会被作为一个单词列表处...