String sql="select s_id as sid,s_name as sname,s_sex as ssex,s_brith as sbrith from stu";

       List list=this.getJdbcTemplate().query(sql,new BeanPropertyRowMapper(Stu.class));

       return list;

    }

关于execute和update方法之间的区别，update方法返回的是受影响的记录数目的 一个计数，并且如果传入参数的话，使用的是java.sql.PreparedStatement,而execute方法总是使用 java.sql.Statement,不接受参数，而且他不返回受影响记录的计数，更适合于创建和丢弃表的语句，而update方法更适合于插入，更新 和删除操作，这也是我们在使用时需要注意的。

Connection conn=DataSourceUtils.getConnection(getJdbcTempldate().getDataSource());

conn=getJdbcTemplate().getNativeJdbcExtractor().getNativeConnection(conn);

OracleConnection oconn=(OracleConnection)conn;

通过DataSourceUtils获取当前线程绑定的数据连接，为了使用线程上下文相关的事务，这样写是正确的写法，如果直接从DataSource获取连接，得到的是和当前线程上下文无关的新的数据库连接实例。

http://www.javaeye.com/topic/49932?page=2

http://www.javaeye.com/problems/15846

http://www.javaeye.com/topic/87034

http://www.javaeye.com/topic/508799

http://ttitfly.javaeye.com/blog/151560

jdbcTemplate的方式里如果带上int[] argTypes显示指定每个占位符所对应的字段数据类型，可以保证类型安全，当参数值为null时，提供了更好的支持。

-----------------------

上面这句话如何理解？

后在http://javazoo.bokee.com/viewdiary.15850865.html找到原因了

今天在调试程序的时候,在后台业务逻辑类中利用JdbcTemplate进行数据同步操作时,发现当
执行jdbcTemplate.update(带?的SQL语句,new Object[]{tmp.getName( ),tmp.getNo( ),tmp.getSpeciality( ),tmp.getMounterofficer( ),tmp.getDesigner( ),tmp.getProductivity( ),tmp.getState( ))
这种操作时,如果后面参数中有值为null时,后台会报异常,细想下也是,如果是null,那就要执行jdbc的setNull(Spring底层还是用JDBC做的)方法了,但是setNull方法要知道具体的数据库字段的类型.如setNull(1,Types.VARCHAR).而在上面的方法没有体现.
终于体会到update方法中第三个参数new int[]的作用了.!
spring还是很伟大的.

如果字段名和属性名是严格对应的，那么就可以不用自己写RowMapper了，使用BeanPropertyRowMapper:

getJdbcTemplate().query(sql, new BeanPropertyRowMapper(User.class));  

类的属性字段名称要数据库中的字段名称一样或者数据库字段名为s_id类的名称为SId,
如果你没有遵守这个规范则可以在select语句后面给数据库字段名取别名

//绑定参数时，日期类型的写法,未经过验证

    public void updStu(Stu stu) {
String sql = "update stu set s_name=?,s_sex=?,s_brith=? where s_id=?";
Object[] obj = new Object[] { stu.getSname(), stu.getSsex(),new java.sql.Date(stu.getSbrith().getTime()), stu.getSid() };
      getJdbcTemplate().update(sql, obj, new int[] { Types.VARCHAR, Types.VARCHAR,Types.DATE, Types.INTEGER });
    }

ConnectionCallback的用法，使用完要手动关闭连接吗？

spring的AbstractRoutingDataSource，可以多态切换数据库?

事务抽象层http://blog.csdn.net/congqian1120/archive/2008/01/16/2046311.aspx

public interface ConnectionCallback

Generic callback interface for code that operates on a JDBC Connection. Allows to execute any number of operations on a single Connection, using any type and number of Statements.

This is particularly useful for delegating to existing data access code that expects a Connection to work on and throws SQLException. For newly written code, it is strongly recommended to use JdbcTemplate's more specific operations, for example a query or updat variant.

doInConnection

ObjectdoInConnection(Connection con)
                      throws SQLException,
DataAccessException

Gets called by JdbcTemplate.execute with an active JDBC Connection. Does not need to care about activating or closing the Connection, or handling transactions.

If called without a thread-bound JDBC transaction (initiated by DataSourceTransactionManager), the code will simply get executed on the JDBC connection with its transactional semantics. If JdbcTemplate is configured to use a JTA-aware DataSource, the JDBC Connection and thus the callback code will be transactional if a JTA transaction is active.

Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see JdbcTemplate.queryForObject etc. A thrown RuntimeException is treated as application exception: it gets propagated to the caller of the template.

Parameters:

con - active JDBC Connection

Returns:

a result object, or null if none

Throws:

SQLException - if thrown by a JDBC method, to be auto-converted to a DataAccessException by a SQLExceptionTranslator

DataAccessException - in case of custom exceptions

See Also:

JdbcTemplate.queryForObject(String, Class), JdbcTemplate.queryForRowSet(String)

Define of cronExpression

这里有个publish接口容易导致被误用的危险，DAO接口如果是领域模型提出的请求实现，那么这个设计就会很冒风险，因为如果一旦你的DAO接 口publish了，你就要冒着别的正在写domain model的开发人员会耦合于你的接口，一旦你的接口publish了，改动就非常困难了，而且如果一旦发现因为需求分析不够导致的DAO接口逻辑有问 题，那么这个将是非常痛苦的重构/修改过程。
所以关键在于让合理的关联代替复杂的查询。

说到接口，顺便说说对满天飞的interface的反感，我以前就是那样满天飞的，先在感觉飞的太高了。

接口其实就等同于代码隐藏，说句不好听的话就是代码私有化。 我发布一个接口，加上一些比较清晰的说明。 调用着一般都会只看接口说明感觉合适就直接IOC进来用了，久而久之就有可能被误用接口的危险。 如果没有接口，依赖代码就是文档的和相互可以修改的原则，那么大家都可以直入对方的正体，看一下对方代码的具体实现逻辑，有问题可以直接提出来探讨，这样 就减少了程序风险，而且也省去了来来回回反反复复修改interface 和实现的麻烦。
接口就如同是一个盖子，盖住了很多东西，然而在代码极度共享和互改的环境中，还是少用为妙。

呵呵？谁有分布式的需求？

spring不是支持集群了吗？分布式就用不着了吧

有一个收费的T字头的方案能帮助spring实现分布式吧，没有免费的实现是挺麻烦的。

我们的做法是在5台tomcat服务器前面放一台四层交换机之类的硬件，这样，相同的ip来访问时会被指派到同一台tomcat,因此不需要http session共享，也能达到类似的分布式效果，还节约了session共享的消耗。

一直觉得interface就是C++里的.h 头文件，好不容易java里不需要.h,脱了苦海，现在大家又争先恐后再入火坑。

其实如果把interface用于动态proxy, cglib已经提供了解决方案，spring的OAOP,测试时的easyMock,都有cglib实现，性能比基于interface proxy的更高一点点。

如果是代码设计方面的，一定要看清楚实际情况再决定是否抽象interface。我觉得interface在代码设计方面最主要的应用其实是多重继承吧和firebody说的盖子功能吧。

所以springside里只有几个用到多重继承和webservice盖子的时候才用了interface. 比如dao, appfuse等sample为了演示多种dao方案才用interface阿，我们没事又不会换orm方案的，忙活这个接口没意义呀。