dbware1.0.4版本  donnie4w@gmail.com
该版本主要修改的功能：增加数据缓存层。

详细如下：
1，修正了部分1.0.3的bug。

2，增加了数据缓存层。支持结果集缓存。使用方法非常简单,对dbware没有依赖,dbware通过sql的注释来操作缓存：
   在查询sql前增加注释  /* cache=key */  其中cache为关键字，key为自定义的key值。dbware执行查询sql前会先查询缓存是否存在对应的key，如果存在，则直接返回key对于的查询结果集；如果key不存在，则执行SQL，并缓存该key以及对于的结果集。
   在增删改sql前增加注释/* cache=key */。则dbware会删除缓存中对应的key及其结果集，如果是在dbware集群环境中，删除操作会实时同步到集群中的其他机器。
  
   key也可以是多个key:  /* cache=key1,key2,key3…… */

   在select语句前如果是 /* cache=key1,key2,key3…… */ 则会先查询缓存中是否存在key1或key2或key3或……，一旦发现有存在的key，则返回其对应结果集。如果所有key都不存在，则执行查询SQL并逐一缓存key1,key2,key3…及对应的结果集。
  
   在增删改sql前如果是  /* cache=key1,key2,key3…… */ 则会逐一删除各个key及其对应结果集，如果是在dbware集群环境中，删除操作会实时同步到集群中的其他机器。 
   
   使用建议，使用缓存时key的设计很关键。因为除了缓存结果集，还要在必要的时候删除相应缓存，特别当不同的业务服务器共享dbware缓存时，key的建立要有约定的规则，以保证及时更新缓存，防止脏数据的产生。
   
   通过dbware缓存，您可以很轻松的建立一套自己的数据缓存层，在适当的时候删除缓存以确保数据准确性。当然如果在业务服务器中做缓存，那么响应会更快，但是当业务服务器多了或者做负载均衡时，传统的做法是搭建消息通知服务器，更新缓存时通知其他机器更新或删除等，以确保缓存数据的一致性。如果通过dbware做查询SQL的数据缓存则可以省略消息通知服务器的搭建及维护，并且即使脱离dbware，业务逻辑不会受到任何影响。
   
   使用场景：假如有 用户表:t_userinfo  字段:id,name,nickname
   如：缓存用户id为100的信息：   /* cache=userinfo_id_100 */ select id,name,nickname from t_userinfo where id=100;  //缓存结果集
   当id为100的用户信息更新时：   /* cache=userinfo_id_100 */ update t_userinfo set nickname="donnie" where id=100;  //删除结果集
  
3，针对缓存层，提供了命令访问及简单的操作机制。
   端口为dbware.xml中cport节点配置的值。连接方式 如：telnet 127.0.0.1 3355
   出现 dbware 1.0.4
        dbware: (CONNECTED) 0]
    则可以输入相应命令操作。
   提供若干命令，可以输入help查看，如果命令有误，也会直接返回help命令的内容。
   通过命令行，你可以查看服务器简单的信息，删除缓存key（如果集群，会同步到集群中的其他服务器），查看key是否存在。查看key对应缓存结果集大小（单位字节）等。
   退出可以用命令quit或bye

4，sbin文件夹中增加bat启动文件，您可以在windows环境下运行bat文件来启动dbware。

5，支持查询SQL通过加注释/* master */ 直接访问master库。在dbware最初版本中配置dbfilter.xml也是同样的功能，（可以参见dbware最初版本readme.txt），但是配置文件的方式不够灵活，配置之后还要重启，所以增加关键字master，扩展性相对更好。
   如果与此同时也需要使用缓存，则可以用分号;隔开  如：/* master;cache=key */ 
   
6，修正1.0.3版本中不规范的做法：
   
  1.0.3版本的部分描述：
   支持多数据源，主要解決业务场景中多数据库或分库的情况。
   见dbRule.xml配置中：
    <group name="datasource1">
        <master>master1</master>
        <slave>slave1*3,slave2</slave>
    </group>
  <group name="datasource2">
        <master>master2</master>
         <slave>slave3*3,slave4</slave>
    </group>
   这为两组主备数据源。
   所以jdbc访问时要加上对应的数据源名字，也就是对应group 属性name的值
   原来：jdbc:mysql://127.0.0.1:8660/wuxiaodong
   现在：jdbc:mysql://127.0.0.1:8660/wuxiaodong@datasource1

以上jdbc:mysql://127.0.0.1:8660/wuxiaodong@datasource1这样的访问方式不规范，虽然大部分情况下增删改查都不会有问题，但一些场景下，底层驱动发出
show语句，以wuxiaodong@datasource1为数据库名，虽然dbware可以针对这个情况做处理以获取正确数据库名wuxiaodong，但毕竟这样的操作特殊，不能保证适合所有场景。
所以建议不这样使用。还是用传统的方式jdbc:mysql://127.0.0.1:8660/wuxiaodong
在多数据源下，<group name="datasource1"> 建议将 name值配置为相应的数据库名字
如:     <group name="wuxiaodong">
           <master>master1</master>  //master1在dbServer.xml中配置的数据库名字也为wuxiaodong，也就是说这组配置中数据库名称都是wuxiaodong
           <slave>slave1*3,slave2</slave>
        </group>
  <group name="datasource2">
          <master>master2</master>
          <slave>slave3*3,slave4</slave>
        </group>

那么jdbc:mysql://127.0.0.1:8660/wuxiaodong就可以正常的访问到
         <group name="wuxiaodong">
           <master>master1</master>  
           <slave>slave1*3,slave2</slave>
         </group>
   这组数据源了。


当然jdbc:mysql://127.0.0.1:8660/wuxiaodong@datasource1这样的访问方式依然支持，只是不建议使用了。

有任何问题或建议欢迎随时email给我donnie4w@gmail.com，谢谢!
^_^