使用access数据库，tomcat崩溃的问题

#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7c95f350, pid=3964, tid=4024
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0-b64 mixed mode)
# Problematic frame:
# C  [ntdll.dll+0x2f350]
#

---------------  T H R E A D  ---------------

Current thread (0x275ad650):  JavaThread "http-0.0.0.0-80-Processor21" daemon [_thread_in_native, id=4024]

siginfo: ExceptionCode=0xc0000005, writing address 0x00000008

Registers:
EAX=0x00000000, EBX=0x00000000, ECX=0x00000008, EDX=0x00000004
ESP=0x2879ed14, EBP=0x2879ed20, ESI=0x00000008, EDI=0x00000000
EIP=0x7c95f350, EFLAGS=0x00010297

Top of Stack: (sp=0x2879ed14)
0x2879ed14:   00000000 00000000 00000008 2879ed3c
0x2879ed24:   4b784c16 00000004 28a22f8c 4b7527af
0x2879ed34:   28a22f8c 28a22f68 2879ed74 4b758af9
0x2879ed44:   28a22f8c 4b780000 275ad70c 23e621d0
0x2879ed54:   00000001 00000000 2879ed48 2879e940
0x2879ed64:   2879fce8 4b785705 4b758ac8 ffffffff
0x2879ed74:   2879ed8c 4b758a9d 28a22f68 2879edac
0x2879ed84:   26e80418 275ad70c 2879eda4 6d371157

Instructions: (pc=0x7c95f350)
0x7c95f340:   56 8d 72 04 57 89 75 fc b8 00 00 00 00 8b 4d fc
0x7c95f350:   f0 0f b3 01 0f 92 c0 84 c0 0f 84 95 0f 00 00 64


Stack: [0x28760000,0x287a0000),  sp=0x2879ed14,  free space=251k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [ntdll.dll+0x2f350]
C  [ODBC32.dll+0x34c16]
C  [ODBC32.dll+0x8af9]
C  [ODBC32.dll+0x8a9d]
C  [JdbcOdbc.dll+0x1157]
j  sun.jdbc.odbc.JdbcOdbc.allocConnect(J[B)J+0
j  sun.jdbc.odbc.JdbcOdbc.SQLAllocConnect(J)J+30
j  sun.jdbc.odbc.JdbcOdbcDriver.allocConnection(J)J+6
j  sun.jdbc.odbc.JdbcOdbcConnection.initialize(Ljava/lang/String;Ljava/util/Properties;I)V+37
j　org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Lorg/apache/tomcat/util/net/TcpConnection;[Ljava/lang/Object;)V+113
j  org.apache.tomcat.util.net.TcpWorkerThread.runIt([Ljava/lang/Object;)V+159
j  org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run()V+167
j  java.lang.Thread.run()V+11
v  ~StubRoutines::call_stub
V  [jvm.dll+0x8168d]
V  [jvm.dll+0xd4179]
V  [jvm.dll+0x8155e]
V  [jvm.dll+0x812bb]
V  [jvm.dll+0x9bbe9]
V  [jvm.dll+0xfe77f]
V  [jvm.dll+0xfe74d]
C  [MSVCRT.dll+0x2b530]
C  [kernel32.dll+0x26063]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  sun.jdbc.odbc.JdbcOdbc.allocConnect(J[B)J+0
j  sun.jdbc.odbc.JdbcOdbc.SQLAllocConnect(J)J+30
j  sun.jdbc.odbc.JdbcOdbcDriver.allocConnection(J)J+6
j  sun.jdbc.odbc.JdbcOdbcConnection.initialize(Ljava/lang/String;Ljava/util/Properties;I)V+37
j  org.apache.catalina.core.StandardValveContext.invokeNext(Lorg/apache/catalina/Request;Lorg/apache/catalina/Response;)V
J  org.apache.catalina.core.StandardPipeline.invoke(Lorg/apache/catalina/Request;Lorg/apache/catalina/Response;)V
v  ~RuntimeStub::alignment_frame_return Runtime1 stub
j  org.apache.catalina.core.StandardEngineValve.invoke(Lorg/apache/catalina/Request;Lorg/apache/catalina/Response;Lorg/apache/catalina/ValveContext;)V+59
J  org.apache.catalina.core.StandardValveContext.invokeNext(Lorg/apache/catalina/Request;Lorg/apache/catalina/Response;)V
J  org.apache.catalina.core.StandardPipeline.invoke(Lorg/apache/catalina/Request;Lorg/apache/catalina/Response;)V
j  org.apache.catalina.core.ContainerBase.invoke(Lorg/apache/catalina/Request;Lorg/apache/catalina/Response;)V+6
j  org.apache.coyote.tomcat5.CoyoteAdapter.service(Lorg/apache/coyote/Request;Lorg/apache/coyote/Response;)V+137
J  org.apache.coyote.http11.Http11Processor.process(Ljava/io/InputStream;Ljava/io/OutputStream;)V
j  org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Lorg/apache/tomcat/util/net/TcpConnection;[Ljava/lang/Object;)V+113
j  org.apache.tomcat.util.net.TcpWorkerThread.runIt([Ljava/lang/Object;)V+159
j  org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run()V+167
j  java.lang.Thread.run()V+11
v  ~StubRoutines::call_stub

---------------  P R O C E S S  ---------------

Java Threads: ( => current thread )
  0x27aee330 JavaThread "TP-Monitor" daemon [_thread_blocked, id=3580]
  0x27af09a8 JavaThread "TP-Processor4" daemon [_thread_in_native, id=3772]
  0x008f5ab8 JavaThread "Reference Handler" daemon [_thread_blocked, id=812]

Other Threads:
  0x00035040 VMThread [id=320]
  0x00908d00 WatcherThread [id=3184]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Heap
def new generation   total 9216K, used 7249K [0x029b0000, 0x033a0000, 0x05110000)
  eden space 8256K,  87% used [0x029b0000, 0x030c4558, 0x031c0000)
  from space 960K,   0% used [0x032b0000, 0x032b0000, 0x033a0000)
  to   space 960K,   0% used [0x031c0000, 0x031c0000, 0x032b0000)
tenured generation   total 121024K, used 30777K [0x05110000, 0x0c740000, 0x229b0000)
   the space 121024K,  25% used [0x05110000, 0x06f1e668, 0x06f1e800, 0x0c740000)
compacting perm gen  total 22528K, used 22350K [0x229b0000, 0x23fb0000, 0x269b0000)
   the space 22528K,  99% used [0x229b0000, 0x23f83a90, 0x23f83c00, 0x23fb0000)
No shared spaces configured.

起初怀疑是申请数据库连接数过多导致服务器崩溃，优化了连接池，并做了个测试，用上千个线程获得连接，不会导致JVM CRASH。顶多抛得不到连接的警告，最后在机器上不停的开多个浏览器窗口进行刷新页面（首页大概15个IFRAME，每个IFRAME中使用了一个CONNECTION），每次刷新可能会需要15个CONN，大约在刷新很长一段时间后，重现出了此故障。

    在百度和GOOGLE上找了一把，大致原因在SUN官网上看到一个BUG，JDBC-ODBC DRIVER的一个BUG，JDBC-ODBC一般就不应该作为商用，一般就做为测试时使用的驱动，本身JDBC-ODBC驱动对多线程的支持不好，在单线程下跑没有问题，但是在多线程下可能导致JVM CRASH。

     基本找到原因，于是把JDK升级到1.6，期望在1.6中解决了这个BUG，但是事实上升级后还是有这个问题，看来1.6中依然有这个问题.

     于是既然是驱动的问题,索性不用JDBC-ODBC方式驱动,想找一个ACCESS 的纯JDBC驱动，找了很久找到一个HXTT第三方驱动：access.jar

  <dbconfig>
     <type>access</type>
     <driver>com.hxtt.sql.access.AccessDriver</driver>
     <url>jdbc:Access:///../server/default/deploy/web-tomcat50.sar/ROOT.war/res/DBSystem.mdb</url>
     <user></user>
     <password></password>
  </dbconfig>



    更换驱动后，到是没有这个问题了，但是让人更郁闷的是，网上所有的这个三方驱动都是试用版，最多支持50次请求，超过50次会抛出异常导致无法使用，天哪真是越搞越麻烦了。到HXTT官网上一看，这个驱动要卖100欧元，算了，忍了为了个驱动，太不值了，尝试找了个反编译工具，把这个驱动的代码反编译出来，把请求次数限制并抛异常部分去掉，可惜的是代码经过了混淆，反编译出来有很多问题（也是，人家卖100欧元的东西能让你这么轻易搞定吗？）

    浪费太多的时间，为了节省时间，决定不在一棵树上吊死，换了数据库，并采用纯JDBC驱动方式最终解决这个问题，捆扰一时的问题终于解决了。
from:http://blog.csdn.net/foxliucong/article/details/3750873